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

[areohbee]

This would allow people to start filenames with date-time so alphabetical order is same as capture time order, and would create unique filenames (without yet another field) and properly order bursts....

Presently, exif metadata includes subsecond field, but Lr filenaming template stops at full seconds. So for unique filenames, one would have to tack on some kind of sequence number or something as well.

So, as things stand, one can have:

YYYY-MM-DD_HH-MM-SS_{seq-num}_{photog/camera...}

but not (as I would prefer):

YYYY-MM-DD_HH-MM-SS-MS_{photog/camera...}

A side benefit is that filename indicates subseconds between shots in a burst, which is otherwise unavailable in Lightroom without a plugin. Although, I could argue for displaying that too in formatted metadata display, even if only upon mouse-over.

---------------
I would like to use Lightroom import dialog box for importing, instead of the plugin I use now, but it stops just shy of what I need/want still. - this is one of the things. However, if import actions were implemented, that would be enough.

[areohbee]

For those who appreciate the fact that I keep y'all posted... (please ignore if you are not one of those).

In the interest of naming such that:
- alphabetic order matches capture time order, even if all photographs were exported to a single flat folder.
- multi-photographer/multi-camera considerations are handled satisfactorily.
- uniqueness is ensured.
- bursts don't required "funny/artificial" sequence numbers or appendages for uniqueness.
- name is still tied to original on card, which usually doesn't matter, but may matter at the beginning or if re-associating via undeleted image on card... and makes me feel good.
- filename is still intelligible to humans, yet not "too" long.

My naming convention has changed to:

{date}{photog}{time}{camera}{image-num}.{ext}

where:

date = YYYYMMDD
photog = 2-char initials, I'm RC
time = HHMMSS - local time zone (toyed with UTC, but I mostly don't travel out of time zone, and if I do, I'll still probably want local time zone, if I can remember to change my camera, and if not, then I get CA time...)
camera = 2-char designation:
char 1 = manufacturer
char 2 = letter corresponding to number owned, or whatever if another photographer (maybe try and distinguish model).
image-num is in-camera image number.

for example:

19950624RC040242NA0001.JPG - for photo taken in 1995 by me using my first Nikon, corresponding to DSC_0001.JPG in camera.
20110624RC040242NB3390.NEF - for photo taken in 2011 by me using my second Nikon, corresponding to _DSC3390.NEF in camera.
20110624GJ040249CX2348.JPG - for photo taken in 2011 by George J using a Canon camera, corresponding to IMG_2348.JPG in camera.

Note: {photog} may be moved right-ward if I ever want multi-photographer photographs interlaced in time. Reminder: this is for alphabetic ordering outside Lightroom after export or when viewing using 'Explorer' (or recycle bin ;-} - oops I meant backup folder...

This solves all my problems without the millisecond field, and is supported by Lightroom import dialog box - I'm one step closer...

I still think milliseconds field should be supported, but it is no longer a pre-requisite to weaning myself from plugin back to the import dialog box.

Please forgive if too many words...

[FeedbackCommunityMember]

I fully support this. Lightroom can currently find itself in a place where it clobbers or swaps data, and sub-second file naming would make this much less likely.

Another way to fix this problem would be to allow the body's image number to be used in file naming. This combined with the serial number would allow for fully unique file naming from supported camera bodies.

[FeedbackCommunityMember]

I fully support this. Lightroom can currently find itself in a place where it clobbers or swaps data, and sub-second file naming would make this much less likely.

Another way to make this much less likely would be to allow the body's image number. This combined with the serial number would allow for fully unique file naming from supported camera bodies.

[FeedbackCommunityMember]

I fully support this. Lightroom can currently find itself in a place where it clobbers or swaps data, and sub-second file naming would make this much less likely.

Another way to make this much less likely would be to allow the body's image number. This combined with the serial number would allow for fully unique file naming from supported camera bodies.

[areohbee]

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).

[FeedbackCommunityMember]

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.

[areohbee]

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...

[FeedbackCommunityMember]

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!

[FeedbackCommunityMember]

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

[areohbee]

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.

[FeedbackCommunityMember]

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.

[areohbee]

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

[FeedbackCommunityMember]

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.

[areohbee]

|> 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...

[FeedbackCommunityMember]

I would also like to see the ability to include the sub-second part of the Exif information in the filename template. The inability to handle burst shot naming is currently the only reason that prevents me from using Lightroom to download files from my memory cards, and I have to use a third-party product.

It is true that not all cameras do provide this information - but if it is not there, just set this field to "00". We can already make use of the camera serial number field, and this is also not provided by all cameras.

[FeedbackCommunityMember]

Please Adobe, high time you sorted this out on your market-leading and expensive software.
Chris Breeze's Breezebrowser has done it very simply for the last 15 years... Just adds 1 or 01 for the first picture, 2 or 02 for the second within the same second, all automatically... All nice and easy, all file names have the same length, and hence are correctly sorted.
Thanks beforehand, Jean-Marie Sohier, jms@sealord.be.

[vtpeters63]

In the File Naming Template Editor in Lightroom 5 you can select the date and time in the EXIF data when renaming photos on import.
Most camera's are capable of capturing a burst of several photos within a second. In Lightroom 5 I have to use a sequence number to differentiate between each photo made within the same second. But after culling my photos (and deleting some that were part of a burst) I'm left with 'gaps' in the sequence numbering.

For renaming my photos instead of using Lightroom I use Adobe Bridge CC.
With Bridge I can use milliseconds (data present in the EXIF, field names SubSecTime, SubSecTimeOriginal and SubSecTimeDigitized) when renaming my photos using Batch Rename. Because there's no sequence number involved after renaming, deleting photos when culling doesn't create 'gaps'.

I'd very much like Lightroom 5 to also be able to use milliseconds in the photo's EXIF data when renaming my photos. It seems the information is present in the EXIF data and Adobe Bridge CC is already using it for its Batch Rename functionality (see attached screen shot).

[FeedbackCommunityMember]

Ugh, they didn't even update this in LR6. Milliseconds is still not an option for the Lightroom 6 rename presets.

[FeedbackCommunityMember]

Lightroom 4.
In the Filename Template Editor you can use Hour, Minute and Second but not Hundredths of a second.
Many cameras can take multi images in a second and also put hundredths into EXIF.

[lhiapgpeonk]

Please make Subseconds for renaming happen soon. Otherwise one had to take a roundtrip to different programs. Just imagine the hassle of:
- Importing photos to Lightroom
- Setting correct time via reference shots
- renaming all photos in Bridge
- Oh no! Lightroom forgot about all images, let me just re-import them...

[vtpeters63]

That's why I have a different workflow...

1. I create a folder on my hard drive with a date and clear description for the photos I want to import and edit (e.g. 20150324__StevenWilson_TivoliVredenburg_Utrecht).
2. I create two subfolders. One named JPG (for holding the exported JPG's) and one named RAW (for storing the original RAW files.
   
3. I simply copy the (RAW) files from the memory card(s) to the RAW folder created in step 2.
   
4. I use Adobe Bridge to rename the files in the RAW folder (using the milliseconds option in Bridge) and add copyright information to the files.
   
5. I open Lightroom and create a new catalogue in the folder that I created in step 1. Lightroom restarts and opens the newly created catalogue.
   
6. I import the already renamed RAW files into this catalogue and  start editing the photos...
   

Because of Lightroom's shortcomings in the file renaming department, I'm forced to do this in Adobe Bridge. The knowledge about how to extract the information from the EXIF is present at Adobe (Bridge can do it), it 'simply' needs to be implemented in Lightroom.

Come on Adobe, you can do it!

[lhiapgpeonk]

Can you set the capture time inside of Bridge? (Same dialog as in LR?) If so, then I would gladly try to embrace Bridge...

[PhilBurton]

Agree with other posters that this capability is long overdue.  My Nikon D3 can burst at 9 frames per second and new models have higher burst rates.

[vtpeters63]

When transferring my photos from my camera's memory card to my computer, one of the first thing I do is batch rename the photos to include their shooting date/time in the name.

Because I shoot in bursts a lot of the times, I have quite a few photos that were shot within the same second.

Renaming these photos in Lightroom results in a sequence numbers being added to the shooting date/time.

After importing the photos in Lightroom I start culling my photos, marking the rejected ones and deleting them. This causes sometimes for 'gaps' in the sequence of photos shot within the same second. To remedy this, I would need to batch rename the photos again.

It would be easier for me if Lightroom were able to include the 'milliseconds' attribute in the date/time of shooting like Adobe Bridge does.

Lightroom knows this 'millisecond' value. The value is visible in the Date Created meta data field in the Library Module (see screenshot below). The field clearly shows "2017-03-31T20:02:15.46", where ".46" is the 'millisecond' part I'm referring to.




I just wish that Lightroom would be able to use the 'millisecond' part for renaming photos, so I can do all my basic editing and organising in Lightroom only and not have to go back to Adobe Bridge just for renaming my photos.

[vtpeters63]

In Bridge, select the folder with the images you want to rename.
Go to menu Tools > Batch Rename to open the rename dialog (see image below).



Here you can select Date Time fields, choose Date Created to find the capture time inside the RAW file and choose the format (YYYYMMDD, HHMMSS and Milliseconds).

Still confused why Adobe won't implement this in Lightroom...