subsecond + shift...

[Alex]

Hey there, not sure if this is a feature request or a bug.

On a (Canon) image with:

Date/Time Original              : 2016:01:01 00:00:07.50
Sub Sec Time Original           : 50

If I execute (+250ms, so we'd expect result 7.75):
exiftool.exe -DateTimeOriginal+=00:00:00.25 *.CR2

I get:
Date/Time Original              : 2016:01:01 00:00:07.50
Sub Sec Time Original           : 50

And if I execute (+750ms, so we'd expect result 8.25):
exiftool.exe -DateTimeOriginal+=00:00:00.75 *.CR2

I get:
Date/Time Original              : 2016:01:01 00:00:08.50
Sub Sec Time Original           : 50

So I can see exiftool is taking existing milliseconds into account in the shift (otherwise +750ms would not increment the second).

However, it does not seem to be updating the ms of either datetimeoriginal or subsectimeoriginal et al.

As microscopic as this might seem, I use exiftool to sync 2 (sometimes 3) cameras taking a shot of the same moment with action (eg a bird being released).  And I'm surprised how often the unchanged ms can reverse the order of the shots because they're named/sequenced by date taken including ms:

"-filename<$DateTimeOriginal$SubSecTimeOriginal%-c.%e" -d %Y%m%d%H%M%S

Anyway I've written a script to fix but it's very freaking slow seeing it must calculate each ms shift file by file.

So, is there a way to get exiftool shifting ms en masse?

Thanks, and PS exiftool totally rocks - don't let my whining give the wrong impression!

Best,
Alex

using Win 8.1 x64
exiftool 10.10
batch file (cmd.exe)

[StarGeek]

The tag you see labled "Date/Time Original" that shows subseconds is most likely SubSecDateTimeOriginal, which is a nonwritable composite tag.  If you use the command Exiftool -DateTimeOriginal -g1 -a you shouldn't get a tag with subseconds.

There may be a better way, but this is the workaround I found.

First, you copy SubSecDateTimeOriginal to XMP:DateTimeOriginal .
Exiftool "-XMP:DateTimeOriginal<SubSecDateTimeOriginal"

Then, run your microsecond change on the XMP:DateTimeOriginal.  This works because XMP timestamps are more flexible than EXIF timestamps.
Exiftool -xmp:DateTimeOriginal+=00:00:00.25

Finally, copy the XMP:DateTimeOriginal to the other timestamps.
Exiftool "-SubSecTimeOriginal<XMP:DateTimeOriginal" "-SubSecTime<XMP:DateTimeOriginal" "-SubSecTimeDigitized<XMP:DateTimeOriginal" "-datetimeoriginal<XMP:DateTimeOriginal"

You'll have to check your images to see what are the proper subsecond tags for your files.  My Nikon based files had SubSecTime, SubSecTimeOriginal, and SubSecDateTimeOriginal.  This command does throw a Warning: Error converting value for ExifIFD:SubSecTimeOriginal (ValueConvInv), but seemed to properly update anyway.

Edit: Command posted doesn't throw a warning.

[Phil Harvey]

This command does throw a Warning: Error converting value for ExifIFD:SubSecTimeOriginal (ValueConvInv), but seemed to properly update anyway.

Odd.  I tried this a number of different ways and didn't see this warning.  If the warning is issued then the tag shouldn't be set.

- Phil

[Alan Clifford]

exiftool -subsectimeoriginal+=10  ahc_7888.nef

subsectimeoriginal is an exif field. This is a Nikon file but I should have thought Canon would be similar.

It results in a change to to composite tag as well:

Code Select Expand

exiftool -subsec* -datetimeoriginal ahc_7888.nef  -G -s
[EXIF]          SubSecTime                      : 30
[EXIF]          SubSecTimeOriginal              : 40
[EXIF]          SubSecTimeDigitized             : 30
[Composite]     SubSecCreateDate                : 2016:02:07 20:22:16.30
[Composite]     SubSecDateTimeOriginal          : 2016:02:07 20:22:16.40
[Composite]     SubSecModifyDate                : 2016:02:07 20:22:16.30
[EXIF]          DateTimeOriginal                : 2016:02:07 20:22:16

[Phil Harvey]

Hi Alan,

But what if sub-seconds was 95 before you added 10?  Then the result should be 05 and the seconds should be incremented.  I think this is why StarGeek suggested going through the XMP date/time tag, which makes sense to me.

- Phil

[Alan Clifford]

I tried it

Code Select Expand

[EXIF]          SubSecTimeOriginal              : 110
[Composite]     SubSecDateTimeOriginal          : 2016:02:07 20:22:16.110

I suppose 110/100 ths would be confusing!  Or could be interpreted as 11/100 ths.

[StarGeek]

This command does throw a Warning: Error converting value for ExifIFD:SubSecTimeOriginal (ValueConvInv), but seemed to properly update anyway.

Odd.  I tried this a number of different ways and didn't see this warning.  If the warning is issued then the tag shouldn't be set.

Yeah, subtle difference between the command I used and the command I posted.  XMP:DateTimeOriginal vs DateTimeOriginal.  The command that returned the warning was exiftool -P -overwrite_original "-SubSecTime<Datetimeoriginal" but no warning returned with exiftool -P -overwrite_original "-SubSecTime<XMP:Datetimeoriginal".  But the SubSecTime is still getting updated with the first command.

[StarGeek]

I tried it

Code Select Expand

[EXIF]          SubSecTimeOriginal              : 110
[Composite]     SubSecDateTimeOriginal          : 2016:02:07 20:22:16.110

I suppose 110/100 ths would be confusing!  Or could be interpreted as 11/100 ths.

I think it ends up being interpreted as 110/1000ths.  At least by exiftool.  Who knows what happens in other programs.

[Hayo Baan]

I tried it

Code Select Expand

[EXIF]          SubSecTimeOriginal              : 110
[Composite]     SubSecDateTimeOriginal          : 2016:02:07 20:22:16.110

I suppose 110/100 ths would be confusing!  Or could be interpreted as 11/100 ths.

I think it ends up being interpreted as 110/1000ths.  At least by exiftool.  Who knows what happens in other programs.

And that is, I'm quite certain, how it should be done; subsectime is the part after the decimal dot of the seconds; a value of e.g., 2 therefore is 2/10, not 2/100 (Interestingly, only my Nikon D4 writes single digit numbers, my other Nikon cameras all write (only) double  digits...)

[Alex]

Thanks StarGeek, really appreciate it - sorry took me a few days to get back and try it.

So I've wound up in another odd spot I wanted to ask about.

I decided to try iterating the images (via batch) and writing all 3 steps per file into an argfile, with one -echo per file/all steps, and then running the argfile eg:

exiftool.exe -@ argfile.txt

It worked except for the lag on the console (no output until the last file's updated).

So then I tried used -v0 and -progress when invoking the argfile eg: exiftool.exe -progress -@ argfile.txt

This also worked - now I can see my echo as each file updates, almost perfect.

Except for a single starting line that outputs at the start of the execution:

(using -v0)
======== FIRST_PIC.CR2

(using -progress)
======== FIRST_PIC.CR2 [1/1]

I gather from the "[1/1]" that in this context, -progress and -v0 is treating the whole argfile as one image (eg because the argfile contains many images, and no subsequent images have this line).

So it there any way to suppress that first line?

I understand that if I add -progress before every appropriate -execute, I'll end up with ======== PIC.CR2 [1/1] per file as well as my -echo.  Ideally I'd just use my echo however, since I'm controlling the message.

Thank again,
Alex

[Phil Harvey]

The -progress option will count all images processed in a single command.  If you are using the -execute option, this effectively separates things into multiple commands.

For example:

Code Select Expand

> cat a.args
a.jpg
b.jpg

> exiftool -@ a.args -filename -progress
======== a.jpg [1/2]
File Name                       : a.jpg
======== b.jpg [2/2]
File Name                       : b.jpg
    2 image files read


- Phil