Ante-scriptum: I present below another case of specific aspect ratios, but, I do wonder if the entirety of aspect ratio calculations needs to be revisited. I speak below of a new, mysterious 14:9 aspect ratio appearing in 1.11.5, but there are others as well, e.g., a "9:7" which I had never seen before either... OR, this IS normal as part of a new-founded way to do things? IDK.
See my earlier post, currently in "Closed/Resolved", first. I think everything discussed there is pertinent here as well.
XnView: MP 1.11.5 - 64 bit (this issue did not exist at version 1.11.2)
OS: Windows 10 Home - 64 bit
In the previous post linked-to above, the problem was with 7:6 and 6:5 ratios wrongly categorized as 6:5 or 5:4 respectively.
Here, I report a new issue, that is, "golden ratio" (1:1.618) aspect ratios are grouped as 16:10 aspect ratios (now reported by XnView as 8:5; I will use this hereafter), and 8:5 ratios are now categorized as 14:9 (a new ratio I had not seen in earlier versions).
I suspect that the golden ratio images will just need to live in the 8:5 category, and that's OK. I'm stupid fussy about my cropping; using both 8:5s AND golden ratios is absurd on my part, but grouping them both as 8:5s is perfectly reasonable.
So, the following only looks at the 8:5s incorrectly categorized as 14:9s.
I sampled 20 recent images now landing in the 14:9 category. I know that I cropped all of them using Affinity Photo 2's crop tool set to a 8:5 aspect ratio (but 16:10 in the following images). 13 of them had an additional row of pixels included because the crop tool, set to an obligatory 8:5, lands on a partial row of pixels.
Here's an example of what that looks like (all images are screen shots, 8:5 (16:10) crop tool activated (the white lines), highly zoomed in on a corner of the image):
To not leave alpha on the edge of the image, the program keeps all of the partially covered row. Thus, for these 13 images, the problem might be due to a lack of rounding when the image is slightly larger than exactly 8:5 (see JLM's observations in the earlier post).
However, and perhaps more troubling, there were 7 images where all four edges of the crop tool fall on exact and complete pixel rows:
Here's the upper-right corner of one such image:
and here's the lower-left corner of that same image:
This seems more problematic. It would seem to me that the 7 images with "perfect" (no partial pixel lines) 8:5 crops should be in the 8:5 category...
Note too that all of the above screen captures were cropped using that same crop tool set to 16:10 (8:5).
Thanks and good day to all!
[1.11.5] 16:10 (8:5) and "golden ratio" aspect ratios grouped incorrectly in Catalog Filter > Properties > Aspect ratio
Moderators: xnview, Dreamer
-
KLE-France
- Posts: 140
- Joined: Mon Jan 14, 2019 3:00 pm
[1.11.5] 16:10 (8:5) and "golden ratio" aspect ratios grouped incorrectly in Catalog Filter > Properties > Aspect ratio
You do not have the required permissions to view the files attached to this post.
-
xnview
- Author of XnView
- Posts: 47983
- Joined: Mon Oct 13, 2003 7:31 am
- Location: France
Re: [1.11.5] 16:10 (8:5) and "golden ratio" aspect ratios grouped incorrectly in Catalog Filter > Properties > Aspect ra
do you have sample files?
Pierre.
-
jkm
- Posts: 610
- Joined: Sat May 11, 2024 12:43 am
Re: [1.11.5] 16:10 (8:5) and "golden ratio" aspect ratios grouped incorrectly in Catalog Filter > Properties > Aspect ra
KLE, I agree with your sentiments, and it’s ok to be “fussy” about aspect ratios.
But arguments like this (and similar in your previous thread):
The ONLY thing that matters is pixel dimensions and mathematical ratios, so best to keep this on point:
ALL aspect ratios (like 16:10 or 16:9) have a numerical value. For 16:10 it is 1.6000; for 16:9 it is 1.7778 approximately. Those two ratios differ by 10-11% (depending on how you calculate).
The only correct way for the app to group by aspect ratio is to calculate the numerical value of the ratio, and allow a certain set percentage tolerance range, like +/- 3%.
So for example, 16:10 +/- 3% is 1.552 to 1.648, and any image with a numerical aspect ratio in that range would be grouped as 16:10 (or 10:16 depending on orientation).
If two aspect ratios are closer together than the standard tolerance, then a choice must be made: either the standard tolerance must be lowered, or one of the ratios must be excluded.
It’s that simple.
There will always be images that are 1 pixel too many or too few to meet the definition. That’s math.
I will point out that the inclusion of the "Golden Ratio" is potentially problematic, as it is only about 1% away from the VESA standard 16:10. Inclusion of the Golden Ratio will at best cannibalize many 16:10 images, and at worst, lower the tolerance so much (1% instead of 2% or 3%) that many many more images will not be readily grouped. My advice would be to just let "Golden Ratio" images be lumped in with the 16:10 standard.
What I think is NOT correct, is what the app was doing in an example from the previous thread: an asymmetrical tolerance, like -2% / +0%
So I don’t think sample files should be needed…
Pierre should ensure the calculation is being done in the correct way, share what the tolerance range is, and that’s it.
Edit: In case Pierre wants it, here is a table of common aspect ratios, sorted by decimal, in both comma and space separated format.
The ones with decimals in the ratio, like 2.39:1, are cinematic aspect ratios (films/movies).
I’d not suggesting all these be explicitly listed. If I recall correctly, when the Aspect Ratio property tree was first created, we just defined all ratios larger than a certain value as “Panoramic”.
But arguments like this (and similar in your previous thread):
have no value and are beside the point. How Affinity Photo or any other app does its cropping is of absolutely no interest or relevance. In short, who cares.KLE-France wrote: Tue Jun 30, 2026 1:52 pm I sampled 20 recent images now landing in the 14:9 category. I know that I cropped all of them using Affinity Photo 2's crop tool set to a 8:5 aspect ratio (but 16:10 in the following images). 13 of them had an additional row of pixels included because the crop tool, set to an obligatory 8:5, lands on a partial row of pixels.
The ONLY thing that matters is pixel dimensions and mathematical ratios, so best to keep this on point:
ALL aspect ratios (like 16:10 or 16:9) have a numerical value. For 16:10 it is 1.6000; for 16:9 it is 1.7778 approximately. Those two ratios differ by 10-11% (depending on how you calculate).
The only correct way for the app to group by aspect ratio is to calculate the numerical value of the ratio, and allow a certain set percentage tolerance range, like +/- 3%.
So for example, 16:10 +/- 3% is 1.552 to 1.648, and any image with a numerical aspect ratio in that range would be grouped as 16:10 (or 10:16 depending on orientation).
If two aspect ratios are closer together than the standard tolerance, then a choice must be made: either the standard tolerance must be lowered, or one of the ratios must be excluded.
It’s that simple.
There will always be images that are 1 pixel too many or too few to meet the definition. That’s math.
I will point out that the inclusion of the "Golden Ratio" is potentially problematic, as it is only about 1% away from the VESA standard 16:10. Inclusion of the Golden Ratio will at best cannibalize many 16:10 images, and at worst, lower the tolerance so much (1% instead of 2% or 3%) that many many more images will not be readily grouped. My advice would be to just let "Golden Ratio" images be lumped in with the 16:10 standard.
What I think is NOT correct, is what the app was doing in an example from the previous thread: an asymmetrical tolerance, like -2% / +0%
So I don’t think sample files should be needed…
Pierre should ensure the calculation is being done in the correct way, share what the tolerance range is, and that’s it.
Edit: In case Pierre wants it, here is a table of common aspect ratios, sorted by decimal, in both comma and space separated format.
The ones with decimals in the ratio, like 2.39:1, are cinematic aspect ratios (films/movies).
I’d not suggesting all these be explicitly listed. If I recall correctly, when the Aspect Ratio property tree was first created, we just defined all ratios larger than a certain value as “Panoramic”.
Code: Select all
Aspect Ratio,Decimal
1:1.618 0.0618
9:21 0.43
9:16 0.56
10:16 0.63
2:3 0.67
5:7 0.71
1:1.14 0.71
3:4 0.75
8.5:11 0.77
11:14 0.79
4:5 0.8
8:10 0.8
5:6 0.83
1:1 1
1.19:1 1.19
6:5 1.2
5:4 1.25
14:11 1.27
11:8.5 1.29
4:3 1.33
1.35:1 1.35
1.37:1 1.37
7:5 1.4
1.41:1 (sqrt(2):1 or A series) 1.41
3:2 1.5
16:10 1.6
1.618:1 1.618
1.66:1 1.66
1.75:1 1.75
16:9 1.78
1.85:1 1.85
2:1 2
2.20:1 2.2
21:9 2.33
2.35:1 2.35
2.39:1 2.39
2.40:1 2.4
2.55:1 2.55
2.76:1 2.76
32:9 3.56
4:1 4
Aspect Ratio,Decimal
1:1.618,0.0618
9:21,0.43
9:16,0.56
10:16,0.63
2:3,0.67
5:7,0.71
1:1.14,0.71
3:4,0.75
8.5:11,0.77
11:14,0.79
4:5,0.8
8:10,0.8
5:6,0.83
1:1,1
1.19:1,1.19
6:5,1.2
5:4,1.25
14:11,1.27
11:8.5,1.29
4:3,1.33
1.35:1,1.35
1.37:1,1.37
7:5,1.4
1.41:1 (sqrt(2):1 or A series),1.41
3:2,1.5
16:10,1.6
1.618:1,1.618
1.66:1,1.66
1.75:1,1.75
16:9,1.78
1.85:1,1.85
2:1,2
2.20:1,2.2
21:9,2.33
2.35:1,2.35
2.39:1,2.39
2.40:1,2.4
2.55:1,2.55
2.76:1,2.76
32:9,3.56
4:1,4