79 Messages
•
1K Points
Tue, Jul 23, 2019 9:26 AM
1
Filenames with leading zeros sort incorrectly in grid view
If a filename contains leading zeros then they appear in the wrong sequence in grid view
For example, files where the first digits are:
0023
01
02
023
024
03
should appear in the order shown above. Lightroom classic in grid view lists them as
01
02
0023
023
024
03
Which is not correct.
LR Classic 8.3.1 on MacOS 10.13.6
For example, files where the first digits are:
0023
01
02
023
024
03
should appear in the order shown above. Lightroom classic in grid view lists them as
01
02
0023
023
024
03
Which is not correct.
LR Classic 8.3.1 on MacOS 10.13.6
Ideas
•
Updated
a year ago
30
8
1
Helpful Widget
How can we improve?
Tags
No tags available
Responses
lumigraphics
1K Messages
•
17.1K Points
a year ago
I'm not sure there is a standard for how to sort these filenames.
0
0
Lauca
100 Messages
•
1.8K Points
a year ago
0
0
stephen_leggett
79 Messages
•
1K Points
a year ago
Consequently the field should be sorted as a text field which would place 00 before 01
Here is a longer example, with some of the non-numeric parts deliberately repeated
For example, files where the first digits are:
0023 - File F
01 - File G
02 - File Z
023 - File G
024 - File K
03 - File W
should appear in the order shown above. Lightroom classic in grid view lists them as
01 - File G
02 - File Z
0023 - File F
023 - File G
024 - File K
03 - File W
Which is not correct.
I put this second set, the LR sequence into Excel, as text fields, sorted ascending and they get reordered into the first, i.e. correct sequence.
0
0
lumigraphics
1K Messages
•
17.1K Points
a year ago
2
0
dan_hartford
519 Messages
•
12.6K Points
a year ago
Where this first changed is in the treatment of dates. If I have two dates. 1/2/2010 and 10/2/2010 which should come first? If treated as an alphanumeric character, a "/" sorts after a "0" as I recall so October would come before January in the YMD system. However if the SW treats them as "dates", then they sort into calendar order.
So, over time (and due to numerous complaints like why is October before January) most SW has put in logic to treat such fields as hybrid data. In other words, portions of the data that look like numbers or dates are treated as such. So "ABC002" would be treated as an Alpho portion followed by a numeric portions and "ABC002" would sort after "ABC1" (as the "002" and "1" are treated as numeric values not alphanumeric values). In many cases the SW will do this only when it finds such numeric data anywhere in the field but other SW only does it if the numeric values are at the beginning or end of the filed or surrounded by "break" charachters such as spaces or hyphens or underscores. Unfortunately there is no standard as it all depends on context and the whims of the developers.
So, the way LR sorts file names in your example is not INCORRECT. It may not be the way you desire, but it is correct in that it is putting files in order numerically based on the first part of the data (the string of digits) and then is using the non numeric part as a secondary sort so that File F comes before File G as they are both numerically 23.
IMHO if Adobe changed this to pure Alphanumeric sorting, I would understand it and be OK with it but I suspect a large majority of LR users would be quite perturbed and would complain in large numbers.
1
david_golding_1mvs2lwngpf9v
162 Messages
•
2K Points
a year ago
0001
0002
0003
not
01
0002
003
Basically 003 does not equal 0003
0
0
stephen_leggett
79 Messages
•
1K Points
a year ago
LR has a bug that was first reported 8 years ago by someone else, reproduced by others, including me and still hasn't been fixed.
That is, when you publish a file, LR contains code to avoid filename clashes in the target and will append "-<number>" when it thinks there will be a clash. That bit of code generally believes that 003 does not equal 0003. But not always! And more often it discards the numeric part completely, so 003 can be the same as 004 and/or 005 and/or 006
So lets say you start with files where what follows the number is the same;
003 - FileA.nef
0003 - FileA.nef
and publish jpg's
Generally the LR code will say 003 is not 0003 and create
003 - FileA.jpg
0003 - FileA.jpg
but sometimes it evaluates 003 and 0003 as identical and produces
003 - FileA.jpg
0003 - FileA-2.jpg
Its not predictable which of the two the outcome will be.
That is, if you run it again you may well get a different outcome, or the same as before. So, checking and renaming the output to remove he spurious -2 just creates a different problem down the line should you need to republish.
Or you might start with
005 - FileB.nef
006 - FileB.nef
and end up with
005 - FileB.jpg
006 - FileB-2.jpg;
so in this case 005 has been evaluated by LR to be the same as 006
Now there are ways to reduce the probability of this happening, which is when I noticed that in grid view 023 and 0023 are the same, yet may or may not be identical be in publish.
Would be easier if I had control over all of the FIleA bits in the above examples but I don't, plus there are about 45,000 older images with three digits and 6,000 more recent with four
Just have to live with this "feature" as given the number and sources of the images to make it consistently four digits isn't feasible and still wouldn't solve the issue with publish.
0
0
John_R_Ellis
Champion
•
5.5K Messages
•
97.2K Points
a year ago
1