Exiftool - processing multi-frames per second capture...

[Dariusz Piatkowski]

I use Marcel Müller's 'exiftool' to process all of my Pentax K5's photos...works great, quick....but...the minute I am attempting to process a series of multi-shots, where the date/time stamp is literally down to the same second (my K5 will do 7 frame/sec in high-speed) the exiftool appears to process all the frames, but they progressively get overwritten by the next frame which still carries the same date/time stamp.

I am curious if anyone has found a way to deal with this type of a situation? I will reach out to Marcel to see if this is something he can tweak?

=== START ===

Exiftool 0.2.1
  (C) by Marcel Müller, 2004-2014
Purpose:
  Rename photo file(s) in EXIF format. Convert EXIF
  info contained in the file(s) into OS/2 extended attributes.
  EXIF up to version 2.2 is supported.
  Exiftool is very similar to renamepics.
Usage:
  exiftool [/d] [/e] [/r] [/h] [File]
Parameters:
  /d        Only print complete file information to standard output
            [default: rename file(s) and generate EAs quietly]
  /e        Write EXIF infos to EAs only (don't reaname pics)
  /x        Remove duplicate files
            If the destination name already exists and the file content is the
            same, the source file is deleted.
  /h        Print this help screen, then abort [default]
  File      File name, or template for file names (wildcards: * or ?)
Examples:
  exiftool /d 00000001.jpg > afile
  exiftool *.jpg
Note:
  Run Exiftool before editing your photo files. Non EXIF aware graphics
  software usually destroys the exposure info in EXIF files.

=== STOP ===

Thanks,
-Dariusz

[Paul Smedley]

Hi Dariusz,

I use Marcel Müller's 'exiftool' to process all of my Pentax K5's photos...works great, quick....but...the minute I am attempting to process a series of multi-shots, where the date/time stamp is literally down to the same second (my K5 will do 7 frame/sec in high-speed) the exiftool appears to process all the frames, but they progressively get overwritten by the next frame which still carries the same date/time stamp.

I am curious if anyone has found a way to deal with this type of a situation? I will reach out to Marcel to see if this is something he can tweak?

I can't talk to exiftool, but I use jhead to rename files to "yyyy-dd-mm hh.mm.ss" format - jhead appends an 'a', 'b', 'c', etc to files with the same time stamp.

Cheers,

Paul

[OS4User]

try http://moveton.tk/files/pyExif-20161225.zip

[Dariusz Piatkowski]

Paul!

...I can't talk to exiftool, but I use jhead to rename files to "yyyy-dd-mm hh.mm.ss" format - jhead appends an 'a', 'b', 'c', etc to files with the same time stamp...

I grabbed the latest available OS/2 version of jhead, and while it won't be able to toss the EXIF info into the extended attributes the way exiftool does, I figured I'd give the file rename function a try.

Alright, so of all things, I'm literally stuck on passing the correct parms to the program. As per the jhead's on-line reference page I attempted to use the following CLI : "jhead -n%Y%m%d-%H%M%S test*.JPG" on the following files (only intending for the test*.jpg files to be processed):

12-25-16   1:24p  12135873       21048  2016-12-11_12-48-07.JPG
12-25-16   1:24p  11492426       21048  2016-12-11_12-48-11.JPG
12-25-16   1:24p  11435120       21048  2016-12-11_12-48-12.JPG
12-27-16   8:50a  12135873       19714  IMGP2807.JPG
12-27-16   8:50a  11712403       19714  IMGP2808.JPG
12-27-16   8:50a  11645929       19714  IMGP2809.JPG
12-27-16   8:50a  11492426       19714  IMGP2810.JPG
12-27-16   8:50a  11270096       19714  IMGP2811.JPG
12-27-16   8:50a  11435120       19714  IMGP2812.JPG
12-29-16   9:47a  12135873       19726  test2807.JPG
12-27-16   8:50a  11712403       19714  test2808.JPG
12-27-16   8:50a  11645929       19714  test2809.JPG
12-27-16   8:50a  11492426       19714  test2810.JPG
12-27-16   8:50a  11270096       19714  test2811.JPG
12-27-16   8:50a  11435120       19714  test2812.JPG

...instead of a result I get the following output:

Error : No such file
in file 'test*.JPG'

So as the on-line page suggested, the single '%' may confuse the Win systems and they suggest to use double '%%', which is what I tried as well...no luck....what am I missing? I am guessing it's something trivial....lol!

[Dariusz Piatkowski]

try http://moveton.tk/files/pyExif-20161225.zip

Thanks, but I'm not quite ready to go Python scripting yet...most recently I ran into problems with YUM/RPM install when my previous Python install got in the way...I had subsequently completely removed it and have not gone back. Yes, I do realize that YUM/RPM install does in fact put a working Python on my system, which I checked, at it is working...just would prefer to stay way from that approach for now.

[Dariusz Piatkowski]

Brief overall STATUS update. I emailed Marcel (the author of the utility) regarding the exiftool code changes I think need to be made. I'm no C++ guru, but it does seem rather simple so I'm actually going to take  stab at enhancing exiftool to handle the issue I described in my post above.

If I succeed (LOL) I will let you guys know.

[Paul Smedley]

Hi Dariusz,

...I can't talk to exiftool, but I use jhead to rename files to "yyyy-dd-mm hh.mm.ss" format - jhead appends an 'a', 'b', 'c', etc to files with the same time stamp...

I grabbed the latest available OS/2 version of jhead, and while it won't be able to toss the EXIF info into the extended attributes the way exiftool does, I figured I'd give the file rename function a try.

Alright, so of all things, I'm literally stuck on passing the correct parms to the program. As per the jhead's on-line reference page I attempted to use the following CLI : "jhead -n%Y%m%d-%H%M%S test*.JPG" on the following files (only intending for the test*.jpg files to be processed):

12-25-16   1:24p  12135873       21048  2016-12-11_12-48-07.JPG
12-25-16   1:24p  11492426       21048  2016-12-11_12-48-11.JPG
12-25-16   1:24p  11435120       21048  2016-12-11_12-48-12.JPG
12-27-16   8:50a  12135873       19714  IMGP2807.JPG
12-27-16   8:50a  11712403       19714  IMGP2808.JPG
12-27-16   8:50a  11645929       19714  IMGP2809.JPG
12-27-16   8:50a  11492426       19714  IMGP2810.JPG
12-27-16   8:50a  11270096       19714  IMGP2811.JPG
12-27-16   8:50a  11435120       19714  IMGP2812.JPG
12-29-16   9:47a  12135873       19726  test2807.JPG
12-27-16   8:50a  11712403       19714  test2808.JPG
12-27-16   8:50a  11645929       19714  test2809.JPG
12-27-16   8:50a  11492426       19714  test2810.JPG
12-27-16   8:50a  11270096       19714  test2811.JPG
12-27-16   8:50a  11435120       19714  test2812.JPG

...instead of a result I get the following output:

Error : No such file
in file 'test*.JPG'

So as the on-line page suggested, the single '%' may confuse the Win systems and they suggest to use double '%%', which is what I tried as well...no luck....what am I missing? I am guessing it's something trivial....lol!

Rings a bell... I seem to recall the public build isn't built with wildcard support. Try specifying a single filename and see if it works.

I have a build at http://smedley.id.au/tmp/jhead-2.97-os2-20140607.zip - I think I added wildcard support at the request of someone (I run jhead on my Ubuntu server).

Cheers,

Paul

[Dariusz Piatkowski]

Folks,

Brief update on my part. Marcel Müller released an updated version of EXIFTOOL...it now handles the same date/time stamp EXIF content down to HH:MM:SS and creates a '~1, ~2, ~3...' filenames...so this now works very well.

If you are not looking for the option to put that information into your EA then Jhead is a great option. In fact, it gives you way more controls over the final filename formatting.

I exchanged a few emails with Elbert Pol and he ported the 3.0 version of Jhead over. I tested it, the app handled all the filename wildcard processing, so multiple files and formatting very well as well. Elbert was going to release this as a RPM package.

I never got a chance to test Paul's release since Elbert got in touch with me regarding the 3.0 release.