[MS-Win] Files not displayed in Expected [Set] Order

[PolJS]

[ I believe this is unrelated to:
v1.10 series: Files not displayed in expected order [Solved]
by janus777, We 2026/04/08
viewtopic.php?t=50575 ]

MS-Win 10.0.19045.6456 64bit

I have a folder where I keep camera sample photos [various cameras].

dir shows:

Code: Select all

a7R-V-Y-JG-0072.ARW
a7R-V-Y-JG-0072.JPG
a7V-6364402986.arw
a7V-6364402986.jpg
D500-9352170017.JPG
D500-9352170017.NEF
D5500-Y-A-KIT_0901.JPG
D5500-Y-A-KIT_0901.NEF
D5600-1992586558.JPG
D5600-1992586558.NEF
D700-9248166115.jpg
D750-0266974751.jpg
D7500-6479295152.JPG
D7500-6479295152.NEF
D780-7406705323.JPG
D780-7406705323.NEF
OM-1-Y-JG-040069.JPG
OM-1-Y-JG-040069.ORF
R3-1621932833.CR3
R3-1621932833.JPG
R6II-Y-WB-5O1A0486.CR3
R6II-Y-WB-5O1A0486.JPG
SL2S-1457006077.JPG
SL2S-4770240415.DNG
Z6II-6924198633.JPG
Z6II-6924198633.NEF
Z8-1658994793.JPG
Z8-1658994793.NEF

I have browser sorting [double green arrow button] as “Type | Ascending | Name - numeric order”.

XnViewMP 1.10.5 [also previous versions] shows:

Code: Select all

R3-1621932833.CR3
R6II-Y-WB-5O1A0486.CR3
a7R-V-Y-JG-0072.JPG
a7V-6364402986.jpg
D750-0266974751.jpg
D780-7406705323.JPG
D500-9352170017.JPG
D5500-Y-A-KIT_0901.JPG
D5600-1992586558.JPG
D7500-6479295152.JPG
OM-1-Y-JG-040069.JPG
R3-1621932833.JPG
R6II-Y-WB-5O1A0486.JPG
SL2S-1457006077.JPG
Z6II-6924198633.JPG
Z8-1658994793.JPG
D700-9248166115.jpg
SL2S-4770240415.DNG
D500-9352170017.NEF
D780-7406705323.NEF
D5500-Y-A-KIT_0901.NEF
D5600-1992586558.NEF
D7500-6479295152.NEF
Z6II-6924198633.NEF
Z8-1658994793.NEF
OM-1-Y-JG-040069.ORF
a7R-V-Y-JG-0072.ARW
a7V-6364402986.arw

Expected: first JPEG’s, then Raw’s, alphabetically [just like XnView Classic did (does?)]:

Code: Select all

a7R-V-Y-JG-0072.JPG
a7V-6364402986.jpg
D500-9352170017.JPG
D5500-Y-A-KIT_0901.JPG
D5600-1992586558.JPG
D700-9248166115.jpg
D750-0266974751.jpg
D7500-6479295152.JPG
D780-7406705323.JPG
OM-1-Y-JG-040069.JPG
R3-1621932833.JPG
R6II-Y-WB-5O1A0486.JPG
SL2S-1457006077.JPG
Z6II-6924198633.JPG
Z8-1658994793.JPG
a7R-V-Y-JG-0072.ARW
a7V-6364402986.arw
D500-9352170017.NEF
D5500-Y-A-KIT_0901.NEF
D5600-1992586558.NEF
D7500-6479295152.NEF
D780-7406705323.NEF
OM-1-Y-JG-040069.ORF
R3-1621932833.CR3
R6II-Y-WB-5O1A0486.CR3
SL2S-4770240415.DNG
Z6II-6924198633.NEF
Z8-1658994793.NEF

Switching among:

Code: Select all

Name - numeric order
Name - normal order
Name - alphabetic order

does nothing.

[jkm]

Hi PolJS,

I'll try to clarify what's going on for you.

First, you're correct, this has nothing to do with that other thread. And thanks for trying to search the forum before posting.

This is not a bug (you posted in the bug report board), it's just a misunderstanding of how the app works.

In XnViewMP, JPEGs do not have some special significance where they always come first. They are an image file type just like any other, and when you sort by Type, the "types of type" are sorted alphabetically. And your raw files don't have a generic type of "RAW", they have their own individual types.

And it's not that switching among the different name sort options does nothing; they work fine. But your primary sort is by type, so that supersedes the Name sorting options.

So the app is behaving properly and according to expectations, just not your expectations.

But I'll give you a tip: If you view the sort/column header, it can show you what's going on. If you switch to Details view you'll see it (or you can enable it in any other browser mode with View->Sort By and clicking the "Show Header" box at the bottom of the menu.). If you right-click on the header, you can "Customize Columns" and use this to enable the "Type" column, which will actually show you the file types in Details view.

If you look at the names of the types, that will reveal why they are sorted in the way they are. In your example, you see .CR3 files first because the "Type" for those is "CANON" (not "RAW") and Canon comes before JPEG alphabetically. An .ARW file is of type "SONY" so alphabetically it's after JPEG.

You can reverse the sort on the Type field, if that suits you better. You can also show only the .JPG files by typing jpg in the QuickFilter field, if you have that on your toolbar.

Hopefully this helps...

[user0]

use Extension instead of Type

[xnview]

Expected: first JPEG’s, then Raw’s, alphabetically [just like XnView Classic did (does?)]:

Which sorting method do you use with Classic?

[PolJS]

…
So the app is behaving properly and according to expectations, just not your expectations.
…

Right — great explanation [appreciated!] and yes, it helps me… understand what is going on, not why!

It does not explain two things:

• What purpose does “type” defined thiswise serve?! [Yes, of course, I expect non-raw’s be displayed first, raw’s second, alphabetically — I do not expect photo types being defined by brand… instead of TYPE!]
• What the reason might be for the D700 JPEG to be sorted last [of the JPEG’s], with my preferred settings, but when I sort by Extension same D700 JPEG jumps — correctly! — right after that of the D500.

use Extension instead of Type

Yes, this makes things better, however some raw’s are sorted before the JPEG’s [which are thus sorted in between two sets of raw’s, but in correct alphabetical order] — thanks!

Expected: first JPEG’s, then Raw’s, alphabetically [just like XnView Classic did (does?)]:

Which sorting method do you use with Classic?

I cannot remember, as I have not used it for quite some time, however it does not matter at the moment, because I have made a logical error:
[when I posted] I [had in mind and] compared 2 different scenaria: folders with JPEG’s and raw’s from the same camera vs folders with JPEG’s and raw’s from different cameras — your, as well as jkm’s, replies have made this clear — my apologies!

However, the question is [for me!]: why are photo types defined by XnView in this manner, instead of what I describe and — intuitively! — expect, i.e. simply as 2 general different categories: non-raw’s vs raw’s? [If this serves some purpose, then, kindly, at least, consider giving the option that non-raw’s are sorted before raw’s [or after — separately, also alphabetically!], in a future version!]

[You might also want to read my answers, above, for completeness.]

[jkm]

…
So the app is behaving properly and according to expectations, just not your expectations.
…

Right — great explanation [appreciated!] and yes, it helps me… understand what is going on, not why!

It does not explain two things:

• What purpose does “type” defined thiswise serve?!

I think that's obvious. It's informational, so the users don't have to memorize what the extensions mean.

[Yes, of course, I expect non-raw’s be displayed first, raw’s second, alphabetically — I do not expect photo types being defined by brand… instead of TYPE!]

Then I'm afraid you'll have to get used to disappointment. This is how the application works.

Different raw types are different image formats. Sony is a different file format from Nikon. In the same way that JPEG is a different file format from TIFF. Thinking there should only be one grouping for RAW is like thinking there should only be one grouping for "Cooked" images. Then you'd have RAW vs IMAGE, and no way to sort/distinguish between JPEG/TIFF/PNG/GIF etc. The distinction is the same. Some people think differently than you about images.

But I'll give you one tip at the end of the post that might let you achieve the effect you want...

[*]What the reason might be for the D700 JPEG to be sorted last [of the JPEG’s], with my preferred settings, but when I sort by Extension same D700 JPEG jumps — correctly! — right after that of the D500.[/list]

Again, when you sort by a field like type, it's sorted alphabetically. I'm not arguing with you over why the application sorts in a way you don't like. I'm telling you how it is.

use Extension instead of Type

Yes, this makes things better, however some raw’s are sorted before the JPEG’s [which are thus sorted in between two sets of raw’s, but in correct alphabetical order] — thanks!

Sorting on extension vs type makes no material difference to your complaint. .awr will still be before .jpg, and .nef will still be after .jpg. So you will still be just as upset, unless you rename all your raw files to have the same extension, or at least rename the ones that come alphabetically before .jpg (Sony, Canon, ...), and that's something you should not do.

If you mix different raw types and extensions in the same folder with jpeg, your problem is unavoidable.

If you ONLY have .jpg and .nef in the same folder, then you will not have to be so upset. You can sort by extension OR type, and get the order you want, by using either ascending or descending sort.

You're having a problem because in addition to jpegs, you also have types/extensions that are BOTH before and after jpegs alphabetically.

So you have to either fix that, fix your expectations, or move on.

As I said, the application does not just do RAW vs JPEG as you would like. Sorry.


Here's one tip that may let you achieve your desired effect in a directory filled with sony/canon/jpeg/nikon files...
This will actually give a materially different result in that situation, which sorting by extension will not, as I already explained.

Go to Details View, and add the Bits column. Then sort by Bits by clicking it in the header row. (NO, it is not available on the Sort menu)
JPEGs show in the Bits column as 8 (bits per channel). All those raw formats you're using are seen by XnViewMP as 16 bit per channel files. So they will all sort together under 16 (and alphabetically within 16) and the JPEGs will all sort first as 8.

You can also access that sort in other view modes by showing the column header, which is an option on the Sort menu. Clicking a column header will override whatever sort you selected in the sort menu.

Or, if you want to be clever, simply create a new user-defined tag in your exiftool configuration that returns "RAW" for raw files and "Image" for everything else, and then add that field as a column in XnViewMP and sort by that. Then you'll have effectively extended XnViewMP to behave the way you want.

Good luck...

[PolJS]

Thanks — again!

Still, you might want to investigate what I describe regarding the D700 photo sorting.