The Narrative Clip camera syncs its EXIF-less photos locally to sub-directories in the format of YYYY/MM/DD, with a filename in the format of hhmmss. I have yet to figure out how to tell Exiftool to transfer this directory and filename data into the jpegs. I tried this on a copy of one of the jpegs which I named "210506c.jpg":
exiftool "-datetimeoriginal<{directory}filename" ~/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
To which Exiftool responded:
Warning: No writable tags set from /Users/chuckkahn/Pictures/Narrative Clip/2014/05/02/210506c.jpg
0 image files updated
1 image files unchanged
Another attempt went:
exiftool "-datetimeoriginal<${directory}filename" /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) in ExifIFD:DateTimeOriginal (PrintConvInv) - /Users/chuckkahn/Pictures/Narrative Clip/2014/05/02/210506c.jpg
1 image files updated
I could list more of my attempts made this afternoon, but the results were all negative. How can I get this to work?
P.S.: I should mention that the hhmmss.jpg filename format is UTC time. (I'm in EDT time.) Just getting either time to work would seem like an achievement.
The error message of "Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) in ExifIFD:DateTimeOriginal" pretty much tells you the problem. You're trying to put the entire directory and filename, which is "/Users/chuckkahn/Pictures/Narrative Clip/2014/05/02/210506c.jpg" when the tag wants it in the format of YYYY:mm:dd HH:MM:SS.
Ok, this is messy but my quick test looks like it should work. It uses some of the advanced formatting to capture and backreference the parts of the directory and filename you want and then format it properly. I think I might be missing an easier way to do it and if so, Phil will probably come along and fix it :D
ExifTool "-datetimeoriginal<${directory;s!([0-9]{4})/([0-9]{2})/([0-9]{2})$!\1:\2:\3!} ${filename;s!([0-9]{2})([0-9]{2})([0-9]{2})!\1:\2:\3!}" /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
Edit: slight change to force directory regex to match end of directory.
Quote from: StarGeek on May 11, 2014, 02:04:54 AM
The error message of "Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) in ExifIFD:DateTimeOriginal" pretty much tells you the problem. You're trying to put the entire directory and filename, which is "/Users/chuckkahn/Pictures/Narrative Clip/2014/05/02/210506c.jpg" when the tag wants it in the format of YYYY:mm:dd HH:MM:SS.
Ok, this is messy but my quick test looks like it should work. It uses some of the advanced formatting to capture and backreference the parts of the directory and filename you want and then format it properly. I think I might be missing an easier way to do it and if so, Phil will probably come along and fix it :D
ExifTool "-datetimeoriginal<${directory;s!([0-9]{4})/([0-9]{2})/([0-9]{2})$!\1:\2:\3!} ${filename;s!([0-9]{2})([0-9]{2})([0-9]{2})!\1:\2:\3!}" /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
Edit: slight change to force directory regex to match end of directory.
Thanks for the help. That gets:
event not foundI hoped it would be much simpler based on Phil's reply in this thread, where the path began with "c:\images\" and didn't include the DD or the hhmmss.
https://exiftool.org/forum/index.php?topic=3807.0
It is simpler. You just forgot a '$' in front of "filename":
exiftool "-datetimeoriginal<${directory}$filename" /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
FAQ 5 (https://exiftool.org/faq.html#Q5) explains the required date/time formatting.
- Phil
Quote from: Phil Harvey on May 11, 2014, 07:31:41 AM
It is simpler. You just forgot a '$' in front of "filename":
exiftool "-datetimeoriginal<${directory}$filename" /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
FAQ 5 (https://exiftool.org/faq.html#Q5) explains the required date/time formatting.
- Phil
I'll have to read that faq more carefully, but that isn't working either:
exiftool "-datetimeoriginal<${directory}$filename" /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
Warning: No writable tags set from /Users/chuckkahn/Pictures/Narrative Clip/2014/05/02/210506c.jpg
0 image files updated
1 image files unchanged
Ah. You're on a Mac. You must use single quotes, not double quotes, around arguments containing a dollar sign. The double quotes are used on Windows systems.
Unfortunately you are using bash instead of tcsh, or else you would have got this message from the shell:
directory: Undefined variable.
- Phil
Quote from: Phil Harvey on May 11, 2014, 09:21:36 AM
Ah. You're on a Mac. You must use single quotes, not double quotes, around arguments containing a dollar sign. The double quotes are used on Windows systems.
Unfortunately you are using bash instead of tcsh, or else you would have got this message from the shell:
directory: Undefined variable.
- Phil
Single quotes worked. Yay!
Can time be shifted (UTC to my TZ) in one step or in only via two steps like this?
exiftool '-alldates<${directory}$filename' /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
exiftool -alldates-=4 /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
Hi Chuck,
It does take two steps, but you can combine them into a single command if this is more convenient:
exiftool '-alldates<${directory}$filename' -execute -alldates-=4 -common_args /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
- Phil
Quote from: Phil Harvey on May 11, 2014, 02:58:10 PM
Hi Chuck,
It does take two steps, but you can combine them into a single command if this is more convenient:
exiftool '-alldates<${directory}$filename' -execute -alldates-=4 -common_args /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/02/210506c.jpg
- Phil
Is there a way to combine them into one step? I assume each step re-writes the jpeg, so one step would be faster than two?
Would it be faster still (more jpegs updated per minute) to do this using Image::ExifTool in a perl script instead of as a exiftool command-line?
Doing this via the API won't speed things up unless you can reduce the number of steps. But from the command line, you can reduce the steps to the minimum anyway. You need to create a user-defined tag to do the time shift for you. Search for UserDefined and ShiftTime in the forum and you should find some examples. The only trick may be that you might need to fix the formatting of the date/time a bit. I can't recall how flexible ShiftTime is about the format.
- Phil
Quote from: Phil Harvey on June 29, 2014, 08:47:39 PM
Doing this via the API won't speed things up unless you can reduce the number of steps. But from the command line, you can reduce the steps to the minimum anyway. You need to create a user-defined tag to do the time shift for you. Search for UserDefined and ShiftTime in the forum and you should find some examples. The only trick may be that you might need to fix the formatting of the date/time a bit. I can't recall how flexible ShiftTime is about the format.
- Phil
Is there a syntax for adding more commands? I tried adding a model tag command plus a -r recursive control after the second alldates but when doing multiple folders (the month folder for may, "05", contains day folders "01", "02", etc), the date functions stop writing after a few day folders and only the model tag gets written with no error message appears illuminating the problem.
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 -model='Narrative Clip' -r -common_args -overwrite_original /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/ P.S.:
adding the "-r" to near the end seems to be working better so far...
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 -model='Narrative Clip' -common_args -overwrite_original -r /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/P.P.S:
Spoke too soon. Doing that negates the -4 hour shift. Darn.
Quote from: chuckkahn on June 30, 2014, 07:26:19 PM
Is there a syntax for adding more commands? I tried adding a model tag command plus a -r recursive control after the second alldates but when doing multiple folders (the month folder for may, "05", contains day folders "01", "02", etc), the date functions stop writing after a few day folders and only the model tag gets written with no error message appears illuminating the problem.
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 -model='Narrative Clip' -r -common_args -overwrite_original /Users/chuckkahn/Pictures/Narrative\ Clip/2014/05/
If you want the
-r to apply to the
-alldates command, it must come after
-common_args. Read the explanation of
-common_args in the documentation for details.
Quoteadding the "-r" to near the end seems to be working better so far...
Yes.
QuoteSpoke too soon. Doing that negates the -4 hour shift. Darn.
It shouldn't.
- Phil
Quote from: chuckkahn on June 30, 2014, 07:26:19 PM
QuoteSpoke too soon. Doing that negates the -4 hour shift. Darn.
It shouldn't.
- Phil
If I do it at the date level (2014/05/17) it works if I do it at the month level (2014/05) it doesn't.
Trying at the month level with fresh files (no dates added yet) seems to work.
======== /Users/chuckkahn/Pictures/Narrative Clip/2014/05/28/235954.jpg
Date/Time Original : 2014:05:28 19:59:54
Create Date : 2014:05:28 19:59:54
Modify Date : 2014:05:28 19:59:54Update: this seems so random; same command, different directory (June) results in no camera model being set.
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 -model='Narrative Clip' -common_args -r -overwrite_original /Users/chuckkahn/Pictures/Narrative\ Clip/2014/06 Update again: Is it executing the portion before the "-execute" on all the files in one step and then executing all the commands after "-execute" as a second step so that when I'm checking while it's doing it I'm not seeing the finished two steps of execution? (I'm sure there's a better way of wording that but words fail me.) Is there a way for the exiftool command to display it's progress so that I know where it is (which file, which stage of execution) so that I don't jump to conclusions about it failing?
This command
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 -model='Narrative Clip' -common_args -r -overwrite_original /Users/chuckkahn/Pictures/Narrative\ Clip/2014/06is functionally equivalent to these two commands executed in sequence:
exiftool '-alldates<\${directory}\$filename' -r -overwrite_original /Users/chuckkahn/Pictures/Narrative\ Clip/2014/06
exiftool -alldates-=4 -model='Narrative Clip' -r -overwrite_original /Users/chuckkahn/Pictures/Narrative\ Clip/2014/06The only difference is that you save time by only loading exiftool once.
Quote from: chuckkahn on July 05, 2014, 01:21:18 PM
Is there a way for the exiftool command to display it's progress so that I know where it is (which file, which stage of execution) so that I don't jump to conclusions about it failing?
You could try the
-progress option.
This is all explained in the application documentation.
- Phil
Where does Google+ pick up it's "UTC -4" timezone cues in my iPhone photos?
http://i.imgur.com/5BzJ0du.jpg
ExifTool Version Number : 9.59
File Name : IMG_7810.JPG
Directory : /Users/chuckkahn/Pictures/Camera - iPhone 5S
File Size : 3.3 MB
File Modification Date/Time : 2014:07:04 20:18:04-04:00
File Access Date/Time : 2014:07:20 16:24:40-04:00
File Inode Change Date/Time : 2014:07:20 16:22:50-04:00
File Permissions : rw-------
File Type : JPEG
MIME Type : image/jpeg
Exif Byte Order : Big-endian (Motorola, MM)
Make : Apple
Camera Model Name : iPhone 5s
Orientation : Horizontal (normal)
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Software : 7.1.2
Modify Date : 2014:07:04 20:18:04
Y Cb Cr Positioning : Centered
Exposure Time : 1/570
F Number : 2.2
Exposure Program : Program AE
ISO : 32
Exif Version : 0221
Date/Time Original : 2014:07:04 20:18:04
Create Date : 2014:07:04 20:18:04
Components Configuration : Y, Cb, Cr, -
Shutter Speed Value : 1/570
Aperture Value : 2.2
Brightness Value : 7.792568203
Metering Mode : Multi-segment
Flash : No Flash
Focal Length : 4.1 mm
Run Time Flags : Valid
Run Time Value : 177015423136250
Run Time Scale : 1000000000
Run Time Epoch : 0
HDR Image Type : Unknown (2)
Sub Sec Time Original : 054
Sub Sec Time Digitized : 054
Flashpix Version : 0100
Color Space : sRGB
Exif Image Width : 3264
Exif Image Height : 2448
Sensing Method : One-chip color area
Scene Type : Directly photographed
Custom Rendered : Unknown (2)
Exposure Mode : Auto
White Balance : Auto
Focal Length In 35mm Format : 30 mm
Scene Capture Type : Standard
Lens Info : 4.12mm f/2.2
Lens Make : Apple
Lens Model : iPhone 5s back camera 4.12mm f/2.2
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Altitude Ref : Above Sea Level
GPS Time Stamp : 00:18:03.38
GPS Img Direction Ref : True North
GPS Img Direction : 336.231441
Compression : JPEG (old-style)
Thumbnail Offset : 1830
Thumbnail Length : 10832
Image Width : 3264
Image Height : 2448
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Aperture : 2.2
GPS Altitude : 113.9 m Above Sea Level
GPS Latitude : 43 deg 40' 9.70" N
GPS Longitude : 79 deg 21' 11.15" W
GPS Position : 43 deg 40' 9.70" N, 79 deg 21' 11.15" W
Image Size : 3264x2448
Run Time Since Power Up : 2 days 1:10:15
Scale Factor To 35 mm Equivalent: 7.3
Shutter Speed : 1/570
Create Date : 2014:07:04 20:18:04.054
Date/Time Original : 2014:07:04 20:18:04.054
Thumbnail Image : (Binary data 10832 bytes, use -b option to extract)
Circle Of Confusion : 0.004 mm
Field Of View : 61.9 deg
Focal Length : 4.1 mm (35 mm equivalent: 30.0 mm)
Hyperfocal Distance : 1.87 m
Light Value : 13.1
Because Google+ doesn't read any "UTC -4" from my "exiftool'd" Narrative Clip photos.
http://i.imgur.com/SPeA6mn.jpg
ExifTool Version Number : 9.59
File Name : 005655.jpg
Directory : /Users/chuckkahn/Pictures/Narrative Clip/2014r/07/20
File Size : 804 kB
File Modification Date/Time : 2014:07:20 10:55:46-04:00
File Access Date/Time : 2014:07:20 16:30:01-04:00
File Inode Change Date/Time : 2014:07:20 16:29:41-04:00
File Permissions : rw-r--r--
File Type : JPEG
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Big-endian (Motorola, MM)
Camera Model Name : Narrative Clip
Orientation : Rotate 270 CW
X Resolution : 0
Y Resolution : 0
Resolution Unit : inches
Modify Date : 2014:07:19 20:56:55
Y Cb Cr Positioning : Centered
Exif Version : 0230
Date/Time Original : 2014:07:19 20:56:55
Create Date : 2014:07:19 20:56:55
Components Configuration : Y, Cb, Cr, -
Flashpix Version : 0100
Color Space : Uncalibrated
Image Width : 2592
Image Height : 1944
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)
Image Size : 2592x1944
P.S.: added .csv of the two jpegs.
Perhaps for the GPS location?
The only way to store time zone in standard EXIF is to write GPSTimeStamp (which is UTC) and some other EXIF date/time tag (which is in the local time zone). Although, if your time zone is 12 hours from UTC, you would also have to write GPSDateStamp to be able to differentiate +12:00 from -12:00.
- Phil
Quote from: Phil Harvey on July 20, 2014, 08:47:58 PM
The only way to store time zone in standard EXIF is to write GPSTimeStamp (which is UTC) and some other EXIF date/time tag (which is in the local time zone). Although, if your time zone is 12 hours from UTC, you would also have to write GPSDateStamp to be able to differentiate +12:00 from -12:00.
Hi Phil, nope, it much "simpler" than that. Apparently Google uses the gps location to determine the correct timezone. The image that shows the -4 offset had gps location info, the other didn't. Checking the location reveals that it was a shot taken in Toronto which indeed has the -4 hours timezone offset :)
Cheers,
Hayo
Hi Hayo,
I wasn't making a statement about how Google determines the time zone, they may well do it your way. However, this is an indirect method to determine the time zone. In my opinion it is simpler to just subtract GPSTimeStamp from DateTimeOriginal, rather than to look up the GPS position on a time zone map (and account for regional daylight savings times too).
- Phil
Quote from: Phil Harvey on July 21, 2014, 07:22:37 AM
I wasn't making a statement about how Google determines the time zone, they may well do it your way. However, this is an indirect method to determine the time zone. In my opinion it is simpler to just subtract GPSTimeStamp from DateTimeOriginal, rather than to look up the GPS position on a time zone map (and account for regional daylight savings times too).
Ha, I think I initially misunderstood your comment ;)
Now I read it correctly, I actually think Google may be doing it that way (as it is more direct and a bit simpler). But either way, the point I was trying to make to chuckkahn was that it's because of the GPS info, Google knows what the timzezone is. As there is no GPS information available in the second sample image, google can't determine the timezone.
Quote from: Phil Harvey on July 20, 2014, 08:47:58 PM
The only way to store time zone in standard EXIF is to write GPSTimeStamp (which is UTC) and some other EXIF date/time tag (which is in the local time zone). Although, if your time zone is 12 hours from UTC, you would also have to write GPSDateStamp to be able to differentiate +12:00 from -12:00.
- Phil
I can't find any GPSDateStamp in the iPhone EXIF, so maybe GPSTimeStamp will do for Google+? Also I can't find anything on the exiftool man page about how to write GPSTimeStamp (which would be the same UTC time I pull from the filename using -alldates before I shift it by 4 hours). So is there an -alldatesandgpstimestamptoo command?
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 -model='Narrative Clip' -common_args -r -overwrite_original -progress /Users/chuckkahn/Pictures/Narrative\ Clip/2014P.S.: I just tried re-uploading the same Narrative Clip photo to Google+ and the "UTC-4" came through. The only difference was I used the desktop web page uploader this time. Last time I used the Auto Backup for desktop Mac app.
Soon as I saw the Auto Backup for desktop Mac app uploads appearing without the "UTC-4" on them, I suspended the app. Now I've restarted the app to see if it still does the same.
Quote from: chuckkahn on July 26, 2014, 01:54:42 PM
So is there an -alldatesandgpstimestamptoo command?
Unfortunately GPSTimeStamp is necessarily a bit more strict about the date/time formatting (so it can recognize if there is a date, and skip over it if there is), so you can't set GPSTimeStamp from FileName as you are for AllDates. But you can set it from any of the AllDates tags afterwards, in the same command as your AllDates shift. AllDates is a shortcut for DateTimeOriginal, CreateDate and ModifyDate. So you could do this:
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 '-gpstimestamp<createdate' -model='Narrative Clip' -common_args -r -overwrite_original -progress /Users/chuckkahn/Pictures/Narrative\ Clip/2014- Phil
Quote from: Phil Harvey on July 26, 2014, 08:17:31 PM
Quote from: chuckkahn on July 26, 2014, 01:54:42 PM
So is there an -alldatesandgpstimestamptoo command?
Unfortunately GPSTimeStamp is necessarily a bit more strict about the date/time formatting (so it can recognize if there is a date, and skip over it if there is), so you can't set GPSTimeStamp from FileName as you are for AllDates. But you can set it from any of the AllDates tags afterwards, in the same command as your AllDates shift. AllDates is a shortcut for DateTimeOriginal, CreateDate and ModifyDate. So you could do this:
exiftool '-alldates<\${directory}\$filename' -execute -alldates-=4 '-gpstimestamp<createdate' -model='Narrative Clip' -common_args -r -overwrite_original -progress /Users/chuckkahn/Pictures/Narrative\ Clip/2014
- Phil
That works great. Now I think Google+ Auto Backup for Desktop is mangling the UTC info because uploading that way gives a timestamp with "UTC" but uploading via the web gives the correct "UTC-4" timestamp.
Looks like Google+ Auto Backup for Desktop will pull "UTC-4" from iPhone photos, as this example image uploaded that way shows in the right panel:
http://i.imgur.com/CMowP1U.jpeg
Or check out Google+ post with same minute photos from both cameras:
https://plus.google.com/u/0/103861167345611812134/posts/D4cYMiq17Hv?pid=6040907276026416578&oid=103861167345611812134
So where is Google+ looking and how can I satisfy that in my Narrative Clip photos if gpstimestamp won't?
You can do this investigation yourself by selectively deleting metadata from the iPhone photo until Google+ no longer knows the time zone.
- Phil
Quote from: Phil Harvey on July 28, 2014, 07:42:04 AM
You can do this investigation yourself by selectively deleting metadata from the iPhone photo until Google+ no longer knows the time zone.
- Phil
This does it:
exiftool -gpslongitude= -gpslatitude= And to be precise, Google+ no longer knows it if it is uploaded using the Google+ Auto Backup for Desktop app. Photos uploaded via the web to Google+ preserve the timezone.
https://plus.google.com/u/0/+ChuckKahn/posts/5DvkS9jxVsD