another typo

[web/gag.com] / bdale / blog / posts / Digital_Photo_Creation_Dates.mdwn

diff --git a/bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn b/bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn
index dba0151a2faaeb51326e5c055a0faba91fe4fc61..3399ac2783d50a7e772c9c4eabcc70e39b294ebc 100644 (file)
--- a/bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn
+++ b/bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn
@@ -5,7 +5,7 @@ I learned something new yesterday, that probably shouldn't have shocked me
 as much as it did.  For legacy reasons, the "creation time" in the 
 [Exif](https://en.wikipedia.org/wiki/Exif) metadata attached to digital
 camera pictures is not expressed in absolute time, but rather in some
-arbitrary express of "local" time!  This caused me to spend a long evening 
+arbitrary expression of "local" time!  This caused me to spend a long evening 
 learning how to twiddle Exif data, and then how to convince
 [Piwigo](https://piwigo.org/) to use the updated metadata.  In case I or 
 someone else need to do this in the future, it seems worth taking the time
@@ -69,7 +69,7 @@ important, she needs to make sure her camera's time is correctly set, taking
 advantage of the function that allows here to set the local time from the 
 GPS time.  But of course, that only helps future photos...
 
-# The problem
+# How I fixed the problem
 
 So the problem in front of me was several thousand images taken with the 
 camera's clock "off" by 15 hours and 5 minutes.  We figured that out by a
@@ -83,6 +83,12 @@ plus 4 time zones from home to where the photos were taken.  And the remaining
 was originally set by hand, and drift of the camera's clock in the many 
 months since then.
 
+I thought briefly about hacking Piwigo to use the GPS time stamps, but quickly
+realized that wouldn't actually solve the problem, since they're in UTC and
+the pictures from our phone cameras were all using local time.  There's 
+probably a solution lurking there somewhere, but just fixing up the times in
+the photo files that were wrong seemed like an easier path forward.
+
 A Google search or two later, and I found 
 [jhead](https://www.sentex.ca/~mwandel/jhead/),
 which fortunately was already packaged for Debian.  It makes changing Exif
@@ -92,7 +98,7 @@ Compounding my problem was that my wife had already spent many hours tagging
 her photos in the Piwigo web GUI, so it really seemed necessary to fix the
 images "in place" on the Piwigo server.  The first problem with that is that
 as you upload photos to the server, they are assigned unique filenames on
-disk based on the upload date and time plus a random has, and the original
+disk based on the upload date and time plus a random hash, and the original
 filename becomes just an element of metadata in the Piwigo database.  Piwigo
 scans the Exif data at image import time and stuffs the database with a 
 number of useful values from there, including the image creation time that is
@@ -127,7 +133,7 @@ paths quickly followed:
         done
 </pre>
 
-At this point, all the files on disk wer updated, as a little quick checking 
+At this point, all the files on disk were updated, as a little quick checking 
 with exif and exiv2 at the command line confirmed.  But my second problem
 was figuring out how to get Piwigo to notice and incorporate the changes.  That
 turned out to be easier than I thought!  Using the admin interface to go into
@@ -137,6 +143,5 @@ date range (which I expressed as taken:2019-12-14..2021), then selected all
 photos in the resulting set, and performed action "synchronize metadata".  All
 the selected image files were rescanned, the database got updated...
 
-Voila!
-
+Voila!  Happy wife!