53 Messages
•
872 Points
Fri, Feb 16, 2018 9:49 PM
LR Classic Library sorting behaves unreliable
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.
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.
Problems
•
Updated
3 years ago
1
5
Helpful Widget
How can we improve?
Tags
No tags available
Responses
yves_crausaz
921 Messages
•
14.1K Points
3 years ago
I also have this problem when I shoot in bursts ....
0
0
Johan_Elzenga
Champion
•
3.4K Messages
•
59K Points
3 years ago
Johan W. Elzenga,
http://www.johanfoto.com
0
0
yves_crausaz
921 Messages
•
14.1K Points
3 years ago
0
0
christina_lippok
53 Messages
•
872 Points
3 years ago
@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
2
0
yves_crausaz
921 Messages
•
14.1K Points
3 years ago
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.
0
0