Filenames with leading zeros sort incorrectly in grid view

  • 1
  • Idea
  • Updated 6 months ago
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


Photo of Stephen Leggett

Stephen Leggett

  • 80 Posts
  • 5 Reply Likes
  • mildly annoyed

Posted 6 months ago

  • 1
Photo of David Converse

David Converse

  • 857 Posts
  • 244 Reply Likes
There are different ways to sort numeric data. At my work, we use product part numbers as filenames and many have a leading zero. Excel, Windows Explorer, Mac Finder, Bridge, and Lightroom all sort these a bit differently (Excel actually lets you sort numbers as numbers or text.)

I'm not sure there is a standard for how to sort these filenames.
Photo of Philippe Coudé du Foresto

Philippe Coudé du Foresto

  • 84 Posts
  • 29 Reply Likes
Your logic is true if sorted as number. But it's not true is sorted as text (which it's most often the case for file names)
Photo of Stephen Leggett

Stephen Leggett

  • 80 Posts
  • 5 Reply Likes
Filename is a text field, not numeric. For the sake of brevity I omitted the rest of the filename. 

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. 
Photo of David Converse

David Converse

  • 857 Posts
  • 244 Reply Likes
There is no "correct" way to sort filenames. And Excel can sort numerical values as text or numbers. It pops up a dialog asking if you sort a column that is formatted as text but contains numerical values.
Photo of Stephen Leggett

Stephen Leggett

  • 80 Posts
  • 5 Reply Likes
I'd already said these are not numerical values, these are  alphanumeric

It just happens that SOME of the numbers happen to be leading characters. Excel generally treats mixed fields as text, so if you tell Excel to just sort the data, without specifying its type, it puts it in the first sequence
Photo of David Converse

David Converse

  • 857 Posts
  • 244 Reply Likes
Excel treats values based on cell formatting and whether there is a leading " ' " character in the cell. And mixed values can be listed in different ways. There is no canonical way to sort them.
Photo of Dan Hartford Photo

Dan Hartford Photo

  • 399 Posts
  • 174 Reply Likes
Like many other SW tools,  The distinction between treating numbers as alphanumeric characters (e.g. "0" is just the next letter after "Z") or treating them as numerical "values" has been blurred over the years.  In the old days of computing, a data field was either alphanumeric or numeric period.  If the field was numeric and you put in "123x" the computer would crash. 

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.
Photo of Stephen Leggett

Stephen Leggett

  • 80 Posts
  • 5 Reply Likes
Except in your example, not being in the US,  I'd say that 1st February does indeed come before the 10th. :)

On the other hand I'd agree that whim is exactly the correct phrase

EDIT: Though I think you meant MDY not YMD
(Edited)
Photo of David Golding

David Golding

  • 122 Posts
  • 16 Reply Likes
Incorrect use of leading zeros. Use a consistent number of zeros. Foe example


0001

0002

0003


not


01

0002

003

Basically 003 does not equal 0003
(Edited)
Photo of Stephen Leggett

Stephen Leggett

  • 80 Posts
  • 5 Reply Likes
Afraid that in LR, sometimes 003 does equal 0003 and/or might equal 004, or 005, ...

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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 4790 Posts
  • 1319 Reply Likes
I observe a different ordering in LR grid view: 01, 02, 03, 0023, 023, 024. This is the same ordering used by Mac Finder and Windows File Explorer and is intentional -- see this post for a precise definition.  Since LR is operating as designed, I've changed this topic to a feature request.








Photo of Stephen Leggett

Stephen Leggett

  • 80 Posts
  • 5 Reply Likes
Better still just delete the thing, or archive if not possible

That way my inbox is spared messages about Excel

I'd rather Adobe spend its time fixing some of the real bugs...such as...

Date/Time = 5+Years since reported
FileName on Publish = 8+ Years since reported
Copy MetaData from image to Image = 2+ Years since reported