XnView Software

XnViewMP is not displaying some metadata consistently in different places.

Look at the screenshot below.
In the metadata panel at the bottom, the aperture and shutter speed are correctly displayed.

But look in the columns (details view) of the browser... ShutterSpeed is empty (although Exposure Time is populated, so ok) and Aperture is completely missing.

If the app can display the value in one place (the panel) it should be able to show it in details view. So why is Aperture in the panel but not in the column?

This defect has consequences: because the APERTURE column is totally empty, you simply cannot sort by that value. That's a problem.

Ideally, if the app is incapable of automatically accommodating all the necessary variability of exif data for different cameras to deal with situations like this, there should be an area in the program where we can configure a manual mapping of exif tag values to XnViewMP metadata values; in other words, be able to specify the exif tag that corresponds to Aperture for XnViewMP, like we can do in the thumbnail labels configuration: {EXIF:F-Number}

Can this please be fixed?

please send us a sample file

I sent you a sample file by email.

Currently Aperture field is filled with Aperture field in EXIF metadata, so you would that if Aperture is missing, that we use Fnumber to compute it, right?

In my original post, I see that I wrote like many commonly think of f-stop and aperture as being the same. If someone asks "What aperture did you shoot that at?" you say "5.6". But actually in the world of EXIF, they are technically different.

I think the best solution would be to make Fnumber a sortable column.

Using the Fnumber value for Aperture would be incorrect, since they are two different things, and the values can be quite different.

Different camera manufacturers populate the fields differently, but according to the EXIF specification, we have this:
0x829d FNumber unsigned rational 1 The actual F-number(F-stop) of lens when the image was taken.

0x9202 ApertureValue unsigned rational 1 The actual aperture value of lens when the image was taken. To convert this value to ordinary F-number(F-stop), calculate this value's power of root 2 (=1.4142). For example, if value is '5', F-number is 1.4142^5 = F5.6.

Exiftool says that ApertureValue is displayed as an F number, but stored as an APEX value.

Technically ApertureVaule=LOGsqrt2(FStop) and then rounded. They are equal for some Fstop values, but not all. for f/4, Av=4; for f/2, Av=2, but for f/8, Av=6 and for f/11, Av=7
Canon follows that formula, so both FNumber and Aperture are populated in Canon files, but the values differ.

So copying the ApertureValue into FNumber without doing the correct mathematical conversion (if indeed the camera manufacturer implemented the tags correctly) would produce incorrect results.

As I said, being unable to sort by the Fnumber (which many think of as Aperture) is a problem.

The best thing would be to make FNumber a sortable column. That way the user can sort by the value available, no conversion is necessary, and the user is not deceived as to what values are populated.

Thanks to your detailed description I can reproduce the problem.

This problem is supposed to be fixed in XnView MP 1.9.3. Please check and confirm the bug fix here.

F-Number has been fixed, and that is a big improvement, thank you.

But there are still some other metadata inconsistencies between the EXIF panel and what is shown in details view. I gave F-Number as one example.

In details view:
DPI shows as 0, but shows as 96x96 in the Properties tab of the Info panel; Exiftool panel shows X Resolution=Y Resolution=96
Exposure time of 1/2 shows as 0.50, when all other sub-second exposures show as a fraction.
Ratio always shows as 3:4 when 4:3 is correct.

In the Properties tab, Width and Height are shown correctly for images with the rotation flag set. But in the details tab, they are not.

Example:

For an Image with width=5184, height=3888: properties tab width,height and details view Properties,width,height columns all show 5184x3888; Ratio 3:4
There, the ratio is wrong but the dimensions are correct.


But for an image with the rotation flag set, properties tab width,height = 3888,5184 but details view properties column, width & height columns shows 5184x3888, ratio 3:4.
There the dimensions are reversed (not respecting the rotation flag) but ratio is correct.

I'm sorry if I should have listed all inconsistencies in the original post. I thought you would look at all the inconsistencies, and I was just showing the particularly painful example of F-Number.

DPI, Exposure Time, Ratio, Width, Height, and Properties are all inconsistent with the metadata panel.

While you're in there, it would be great if Lens Model could be added as a column in details view.

jkm wrote: Mon Aug 11, 2025 7:32 am DPI, Exposure Time, Ratio, Width, Height, and Properties are all inconsistent with the metadata panel.

could you send us a sample file?

I sent you a sample file on 3 July. If you need data different from that file, tell me what you need, and I will send you one that has what you want.


However, I just tested some more, and it seems the DPI bug is not data-related but display related. The DPI field will change from 0 to the correct 96 if you switch to Thumbnails+Labels and then switch back to Details.

This also applies to the Width, Height, and Properties columns. The values go to their CORRECT values if you switch between Details and Thumb+Label and back. The Ratio column also "updates" when switching between views, but it is still backwards; see below.

Exposure time problem exists as I stated. 0.50 always shows instead of 1/2

And Ratio is always backwards. You are presenting Ratio as Height:Width when the convention is Width:Height
This becomes clear when the Width,Height columns correct themselves. For an image with Width=3888,Height=5184 the "updated" Ratio column shows "4:3" which is backwards; it should be "3:4".

With your sample file, i can reproduce only the DPI issue. do you use an oriented image file?

The DPI=0 problem happens on ALL files. The other fields being reversed happens on files with the Orientation tag set.

Try this:
Set the browser display to details, and then switch folders a few times. You will see DPI=0.

Then, staying in a folder that is showing DPI=0, switch to Thumbnails+Labels, then switch back to Details. You will see DPI filled out, and files with the Orientation flag set may see their Height and Width values reversed.

Data is getting refreshed/read in Thumbnail view that is not getting read properly in details view.

Other fields that are affected by the orientation tab are also wrong. You must have some files that have the rotation flag set. Browse to those folders in details mode, and look at the other columns I mentioned, like Width and Height. The values will change when you switch to thumbnails view and back.

If you really don't have any files with orientation set, download one here:
https://s3.amazonaws.com/files.prod.dpr ... 146870.jpg
For this image, you should ALWAYS see Height=8192, Width=5464
But XnView does not show those values initialy in Details view; you have to switch to thumbnails and then back to details to see the fields correct.

You can get lots of real-world out of camera images here:
Canon R5 II
Olympus OM-1
Nikon Z8

All of those cameras set the Orientation flag appropriately, so any image you see there that is taller than it is wide has the flag set.

I suggest bookmarking these for future reference, so you have access to good sample images. I hope this helps...

XnviewMP is very good in respecting the orientation flag when displaying thumbnails, which a lot of programs aren't. Something is getting lost when the browser is set to Details view.

reopened