LR Classic Library sorting behaves unreliable

  • 1
  • Problem
  • Updated 5 months ago
I just did a test on renaming and sorting in the library module, because I'm figuring out if I should switch to a more robust file naming scheme (all files retain their name given by the camera at the moment).

The Problem:
Sorting by capture time seems to ignore shutter count and sub seconds once the files have been renamed but instead resorts to filename which - for a burst - is inconsistently named.

How to reproduce:
1. Shoot a high frame rate burst of a clock showing milliseconds like this one: https://codepen.io/jasonleewilson/pen/gPrxwX . You will end up with a lot of images very quickly showing differences partly only in the sub second area. 
2. Adjust the capture time of the photos at leisure (to reflect the photographed time for example)
3. Rename all photos with a more or less unique scheme. I chose "YYYYMMDD_HHMMSS". Note, that I cannot choose to add subseconds, but Bridge lets me do that (as can be seen here: https://feedback.photoshop.com/photoshop_family/topics/lightroom_support_sub_second_milliseconds_field_in_filenaming_templates?topic-reply-list[settings][filter_by]=all&topic-reply-list[settings][reply_id]=19315873#reply_19315873)
4. Naturally there are now duplicate filenames because we have multiple photos per seconds but LR cunningly knows its way around that: all but the first filename get a suffix which is incremented one by one
5. View your images in loupe view ordered by capture time and observe how time and filenames develop over the whole ordered set.

The result you should be getting:
At least in my case the images are shown suffixed files first followed by the un-suffixed file which of course has an earlier capture time. So the images are not in the correct order in the scope of one second. Furthermore, the appended suffix does not start at -1 or -2 but at -5 or -6. This suffix however has no connection to either the last bit of the shutter count or to the sub second portion of the time stamp.

The funny thing:
If you skipped step 2: re-timing the photos, the renamed photos are shown in the correct order, that is un-suffixed file first and then the suffixed files. Talk about consistency.

How I would fix it:
1. Nick the sub-second renaming field code from the Bridge team. They probably won't mind and/or notice :-) There is a request for this since ages: https://feedback.photoshop.com/photoshop_family/topics/lightroom_support_sub_second_milliseconds_field_in_filenaming_templates
2. If encountering multiple files with the same capture time and there is no sub second field (I think Sony cameras are lacking in that respect) order them by shutter count (which should be there for all manufacturers I guess). The original filename won't do, just think of the filename going from DSC_9999.NEF to DSC_0001.NEF. Multiple cameras could be a headache but I would suggest iterating through all cameras if there are no subseconds available so you end up with a burst from one camera first and then from the other one / If the files have different endings like Nikon's .NEF and Canons .CR2 you are fine anyway.
3. When renaming the files (we definetly need sub seconds, that would make things so much easier) start suffixing them from the beginning, so all files in the series have the same file name length, reducing the headache for filename sorting (Probably implemented as a two column list with original filename and new filename as columns. For each new filename test if it is going to occur more than onec, if so get all equal new filenames and append a running index to them starting at whatever you like but probably 0 or 1 to keep it sane)

Why, oh why do I have to re-time the images before renaming them:
Because I want the filename to reflect the actual capture datetime (synced with a GPS tracker) and not some time my camera was off during that shoot. (Think timezones, daylight saving... the things one tends to forget) I know it's pea counting but almost everything is there...

Although I don't know the codebase (I would love to have a peek :-) ) I would imagine that this is something that could be implemented without a complete rewrite of the renaming or sotring module.

I would appreciate if someone familiar with the inner workings of the library could explain how the renaming (I think subseconds are retained as they were) and sorting works (which fields are used). I will keep the "offending" files for a bit, in case they are needed.
Photo of lhiapgpeonk

lhiapgpeonk

  • 48 Posts
  • 4 Reply Likes
  • amused that something seemingly so simple hasn't been implemented yet although it works in another Adobe product

Posted 5 months ago

  • 1
Photo of Yves Crausaz

Yves Crausaz

  • 210 Posts
  • 29 Reply Likes
Maybe the timestamp of the snapshots written in the raws is not precise enough, that the milliseconds are not recorded there and so Adobe can not help it ... The apn makers should think about it too perhaps.

I also have this problem when I shoot in bursts ....
Photo of Johan Elzenga

Johan Elzenga, Champion

  • 1228 Posts
  • 495 Reply Likes
Your camera will name the images in the order they were shot, no matter how fast the burst. So the way I handle this problem is by adding the 'File Name Number Suffix' to the new name. So the new name becomes "YYYYMMDD_HHMMSS_1234", where '1234' is the numbers of the original file name (IMG_1234). That creates unique file names which will sort in the correct order, even with my camera that can shoot 14 fps.
Photo of Yves Crausaz

Yves Crausaz

  • 210 Posts
  • 29 Reply Likes
This is not thé solution....we ave the seconds Orly...and thé sort si on the filename and not the datetime !
(Edited)
Photo of lhiapgpeonk

lhiapgpeonk

  • 48 Posts
  • 4 Reply Likes
Thanks for the replies!
@Yves Crausaz: At least for my NEF's the milliseconds are right there in the datetime fields, so that is not an excuse ;-)
@Johan Elzenga: Adding a unique suffix could be an idea (although one that extends the filename more than strictly necessary). But to prevent problems with the filename going from 9999 to 0001 (happend to me on two trips already!) I woul dhave to either reset the filenumber before every trip or use another field that is unique. I just checked and the unique and steady incrementing (for each camera at least) field of shutter count is not available. Adobe could pack that right in with milliseconds because that field at least should be there for every manufacturer
Photo of Johan Elzenga

Johan Elzenga, Champion

  • 1228 Posts
  • 495 Reply Likes
It's true that a counter rolling over can be a small nuiscance in this setup, but it's very small and I don't see alternatives that are available and better. Yes, if Lightroom would read and add milliseconds that would be better, but the fact is that Lightroom doesn't.

You can easily solve this minor problem by renaming the offending burst, and if you make it a habit of resetting your camera counter(s) every month or so, the problem probably won't occur anyway. Resetting every trip sounds like overkill (unless you shoot more than 10,000 images with a single camera on such a trip).
Photo of lhiapgpeonk

lhiapgpeonk

  • 48 Posts
  • 4 Reply Likes
On the other hand I would have my images start at 1 every time, which is sort of nice ;-)
I will consider it but hope that Adobe gives us more renaming flexibillity anyway :-)
Photo of Yves Crausaz

Yves Crausaz

  • 210 Posts
  • 29 Reply Likes
Looking in the exifs with the plugin "Focus Point Viewer", I see for a raw of Canon .cr2 that there are 2 successive lines having the same title: Date / Time, once the timestamps stops at the second , on the second line, the timestamps stops at the millisecond ....
For raw from Olympus, we do not have the same parameters, but the OS file management parameters (macOS 10.13.3) are given to the millisecond.
So I do not know if for each brand it's different and Adobe should take it into account, it would also be important to display the full values in the metadata fields.

And sorting on the full date/time fields.
(Edited)