P: Support sub-second (milliseconds) field in file naming templates.

|> Daniel said: "I suppose I should begin thinking of a way to embed the chronology into the file rather than using a random number. EG: adding in the sub-second field in sequence based on the original image number or something like that."

I would prefer that, if it were me...

I'd love to assign the subsec field, but in that regard it is a problem that only the manufacturers can solve. For instance, the GoPro HD2 can take 10 photos in a single second, yet they don't use subsecond timestamps. (I have one here and just tested it.) Very frustrating because that's exactly the kind of feature that demands chronological sequence to be maintained, yet neither of our methods can recover the chronology from a random file rename (eg: media recovery by inode number).

I suppose I should begin thinking of a way to embed the chronology into the file rather than using a random number. EG: adding in the sub-second field in sequence based on the original image number or something like that.

Daniel,

I still think it's gonna be a bit of a monstrosity. I mean why not just assign the subsec field you've been talking about, since you're writing an exiftool script to do all this anyway, and if you ever run into a case where the subsec field is unavailable, then modify the script to use a sequence number in place of subseconds, so instead of:

20120324-11-12-6784909873015443.DNG, and
20120324-11-12-0934984752384729.DNG, you'd have

20120324-11-12-03-001.DNG, and
20120324-11-12-03-002.DNG...

Looks nicer, don't you think?

Personally, as I said above, I prefer a scheme that includes photographer and camera designation too, so in case you start shooting with buddies and syncing via strobes..., you can still import them all without risk of conflict, and without changing your filenaming scheme.

Also, you can always parse the folder/file number from the folder/filenames just like Adobe does if you want to put that into your script.

Enough said I imagine...

Rob

Definitely agree, though I expect the random seeding should be taken care of on a system level vs shell script.

Given the other timestamps that are included in the files, namely the date taken, it's highly unlikely you'd ever end up with a duplicate. That is, using a filename like YYYYMMDD-HH-SS-Headline.ext, you'd have a 32^16 chance of having a duplicate. (I used pwgen to get base 36 vs base 16, and only left it at alphanumeric to simply avoid the double-quote which would've made the shell calls fail.) Also, you don't *need* to name your files with the Headline, but there's always the option. One use case I have for this is having recovered a crashed disk by inode number. Under those circumstances, I could expect with almost 100% certainty to end up with unique filenames.

My use case for this is taking one data set, copying a subset of that data, adding to it, then merging back. Using the filenames like I showed above, there would be an almost 100% chance of not having duplicates if you run the script as soon as the images are imported from the camera.

The other concern is that there are some edge cases where you could end up with duplicates. Personally, I'd rather have duplicates than deleted data. DupeGuru can sort out duplicates, but nothing can bring back overwritten files.

Honestly, I'll be happiest when Adobe just decides to use sub-seconds and image count in the native file renaming mechanism of lightroom. Every pro camera supports those fields, and that's where the financially quantifiable cost for losing data comes in.

As long as you don't mind using random numbers to name your files, that'll do it.

Also, you need to make sure you seed the random number generator with a unique seed, like current time, or the numbers won't be random. Also, there is a small chance for non-uniqueness even so, since random numbers may repeat. That's why Adobe uses like 40 character random numbers for UUID's, instead of 16.

Well, that wasn't nearly as difficult as I thought it would be. Feedback is welcome.

#!/bin/bash
###########################
# tag_images_unique.sh by Daniel Hoherd
#
# This script adds a unique ID into the Headline field of images
# if there is no Headline yet. This can then be used to create a
# unique filename that will always be regenerated as the same name
# in case the file gets renamed. EG: disaster recovery scenarios.
#
###########################

## Check for at least one argument, print usage if else
if [ $# -lt 1 ] ; then
echo "This script tags images with a unique number in the Headline field if it is empty."
echo "usage: $0 [image file] ... [image file]"
exit 1
fi

## Requires exiftool
if [ ! -e "`which exiftool`" ] ; then
echo "This script requires the 'exiftool' tool to be in your PATH."
exit 1 ;
fi

## Requires pwgen
if [ ! -e "`which pwgen`" ] ; then
echo "This script requires the 'pwgen' tool to be in your PATH."
exit 1 ;
fi

## Iterate the input tokens
for X in "$@" ; do
## Check if input tokens are files that exist
if [ ! -e "${X}" ]
then echo "File ${X} does not exist"
else
## Check that the given file doesn't already have a Headline tag
if ( ! exiftool -Headline "${X}" | grep -i headline > /dev/null )
then
echo No headline in file ${X}
## Use pwgen to generate a random string
h=`pwgen -s -A 16 1`
echo setting Headline to ${h}
## Set the Headline tag to the random string
exiftool -Headline="${h}" "${X}"
fi
fi
done

Actually I was just using the SDK as a reference for available variables. I dug into the Filename Templates and found some vars, did a search and ended up reading the SDK.

Interesting link. I honestly hadn't even thought about looking for a plugin to handle renaming. I can't believe the built-in LR renaming mechanism doesn't let you use any IPTC or EXIF variable. You can view them, why can't you use them?

I think for simplicities sake (at least in my eyes 😉 I'll stick to my current approach of embedding unique numbers in the Headline field. I'm already a good way into the logic to do so and I've already got a partially CLI based workflow for my imports so it's not too much of a stretch for me. Plus it'll handle the files that don't have sub-second dates or camera body shutter counts. I'll definitely dig more into your plugin though, looks like it'd be a good exiftool reference for me anyhow since I'm still rough on the syntax on a lot of it since it's such a versatile tool. Many thanks for the info!

Daniel, best place to ask SDK questions like this is the SDK forum. These variables are not available to plugins, just the filenaming templates/presets. You can see what I've done in RC Importer, which does support sub-sec field (via exiftool):

http://www.robcole.com/Rob/ProductsAn...

PS - Clever idea for the headline/rename...

What is the variable for the camera body's image number? I was just looking at the SDK and it's not even listed in there. (Page 61 here, I can only find the 3.0 SDK - http://wwwimages.adobe.com/www.adobe....)

I'm playing right now with using exiftool to embed uuid's into the IPTC Headline field in order to have a unique identifier that is seen by lightroom's rename function.

The problem is that not all cameras support the sub-sec field. Obviously, that's fine if you're only importing from cameras that do - but if you ever acquire one that don't, then you've got a problem if you're depending on sub-sec field. I'm not saying it ain't solvable, I'm just sayin'...

PS - The body's image number *is* supported. Reminder: this image number rolls over, which is why I would like Lightroom to support folder number too, since folder numbers don't roll over (before camera wears out...). Combine folder number with image number and you've got a new image number that never rolls over. Couple that with a camera body designator and you've got ensured uniqueness (without resorting to timestamps/sub-sec).