XnView Software

thany2 wrote: Sat Jun 14, 2025 5:05 pm In the crop tool, enter values to crop away, instead of width/height.
So enter how much to take away from each of the 4 sides, rather than being restricted to a width/height, sticking to the little 9-position grid. Granted, it's called canvas resize, not crop tool, so technically you could reason current behaviour is correct. But equally, why would left/right and top/bottom always have to be identical when not cropping from a corner? This is a severe limitation, iyam.

I see no limitations here.
XnView uses the same approach as ACDSee, FastStone/Affinity/Photoshop.
What software with crop tool functionality uses proposed approach?

Hi
I've just updated XnView MP to v 1.9.3 & when I click F3 the file no longer opens in Affinity Photo 2 - & of course AP2 doesn't open either. There's a brief spinning circle & then nothing happens

I've tried to add that in the "open with" dialog, but AP2 is a "Windows App" & that folder has some sort of secret squirrel set up that I can't access.

It was working just fine before the update yesterday.

Windows 10. AP2 is default programme for jpg, dng & orf files, so would have thought it would be listed in XnView MP

Would be most grateful of some advice as to how to fix this

Thanks

Hi. I am not sure if I put this already somewhere else but didn't find it.

Some programs (Affinity, Photoshop?, Image Toolbox, etc..) tell in save dialouge/settings the estimated size of file to be saved. It would be very handy feature for xnmp as you wouldn't have to save multiple files and then start to study in file explorer which one became the size that you want (in the scenario where size is of high importance. Below is illustration how it could look in save dialogue and where it might be easy to put it.

As there are many file formats so it might be challenging to implement it for all of them but it would be cool for most important ones, which are (IMO):

JPG, JXL, AVIF, WEBP,,,, PNG, HEIC, TIF, PDF?, SVG?

The size should update every time you modify saving settings (e.g. change quality parameter, pull quality slider, 4:2:0 to 4:4:4, progressive vs. non progressive encoding, etc...etc...

Thanks for the update. However, the following year (2022) I bought a new laptop with Windows installed and that's what I've been running since. And my patience with GIMP finally ran out so I've switched to Affinity Photo, so ...

But again. thanks.

This seems to be still a bit of wild jungle out there. Here is my observations of lossless rotations:

- there is 3 different tags that might specify lossless rotation, 1. "orientation", 2. "rotation", 3. "cameraorientation"

- orientation is typically part of EXIF data and typically is modifiable (although I run into couple of cases where exiftool was unable to modify it. The "JPEG lossless rotation" if I have not understood incorrectly is simply modifying value in EXIF orientation field and pic viewers then rotate the pic if orientation is anything else than 0 degrees (90, 180, or 270 degrees)

- rotation is less commonly used for still images but HEIC images (iphones) is the large exception. For videos (MP4) rotation seems to be widely used and viewers in general use rotation field to decide how to display the video. Rotation for still images is NOT modifiable in any easy way.

- some digicams save direction to both orientation and cameraorientation. Some save only to cameraorientation which can cause issues when rendering image.


HEIC:
- my phone (S21FE) when taking portrait pic saves value to BOTH orientation and rotation fields. I would assume that maybe same is for iphone HEICs but hopefully somebody here can confirm?

- problems start to arise because only orientation seems to be modifiable but some apps use rotation when rendering and some use orientation. These programs seem to use rotation: XNView MP, MS Photos, Affinity Photo. These programs seem to use orientation: majority of android gallery apps

AVIF:
- currently majority of viewers ignore orientation tag but Samsung Gallery is exception that respects it

JXL:
- MS Photos respect orientation tag, XNView MP ignores it

DNG:
- don't remember anymore which programs use which tag but I assume that probably orientation? Anyway I got this solved by bat file which modifies both in rare situations where I need to rotate a file.


So how this situation should be dealt with? Maybe first read some standards how they specify lossless rotations. Also problem is that no cameras save yet AVIF or JXL pics so there is not yet a large need (except among us who wants to do archiving projects a bit early)

- "enable reading and modifying orientation/rotation for modern file formats"

When this setting is enabled you can
1. apply lossless rotation in addition to JPEG at least to 1. HEIC, 2. AVIF, 3. JXL, 4. maybe others? (dng, webp)
2. when HEIC is rendered renderer reads orientation tag instead of rotation tag
3. when AVIF, JXL, others are rendered orientation tag is read and respected



Lossless rotation is important when you archive large amount of pics but don't have time to search through them for wrong rotations and maybe notice wrong rotation years after and want to rotate without re-encoding (if you pushed hard in first encoding then re-encoding just for 90 deg rotation might be the one step that brings visible artifacts)


Here is what ChatGPT answered about the subject.

xnview wrote: Tue Nov 10, 2020 8:59 pm Pierre check this out if you have any insights

Take for example this image:


In the browser, the background is a light blue (as here in this post), in XnView (which identifies it as JPEG CMYK) it is a bright torquoise.

So I think that some conversion is not right. Could that be?

My current workaround is to use Affinity Photo -> Document -> Convert Profile / ICC Profile... -> Colour Format: RGB/8, Profile: sRGB IEC61... and then export. When I then open it in XnView, it has the correct colors (as expected, because it was converted from CMYK to sRGB).

Whether with or without a selected image, the app entered is not opened. It doesn't matter which app it is, none of them open. I have tried various image editors such as Acorn, the Affinity apps, but also others such as Forklift or FlowVision.

user0 wrote: Tue Apr 15, 2025 5:24 pm

https://community.adobe.com/t5/photoshop-ecosystem-discussions/100-vs-print-size-vs-actual-size-something-stays-unclear/m-p/12074307/page/2#M547713 wrote: 100% is simple - it is 1 screen pixel mapped to 1 image pixel.

Print Size - is calculated from the document resolution and the monitor resolution as manually entered in Preferences.

Actual Size - is calculated from the document resolution and the monitor resolution as reported by the operating system which in turn gets it from the monitor itself using Extended Display Identification Data (EDID). Whilst this needs no manual entering of values by the user, it only works correctly if the correct value is returned from the monitor and OS. Hence print size is also in the menu for cases where an incorrect value is returned.

That's very interesting information, user0, and it would be great to hear from Pierre as to what XnView MP actual does with "Real size."

Indeed, one thing I have noticed, is that XnView MP's "Real size" on-screen does not correspond to the print size reported by my post-processing software, Affinity Photo.

For example, for an image 3728 pixels wide and set to 300 dpi, Affinity Photo reports a print width of 12.427 inches, i.e., 31.56 cm. The enlargement factor for my monitor, i.e., the zoom percentage at which an image's size on-screen corresponds to its printed size at 300 dpi, is 31%. So, when the image is set to that zoom percentage in AP and measured with a physical ruler, one gets 31.56 cm, more or less (as close as one can determine measuring in this way).

Now, when I set that same image to "Real size" in XnView MP and physically measure it with the ruler, I get something close to 32.6 cm.

HOWEVER, XnView MP's status bar correctly reports 31.56 cm for the width, but a zoom percentage of 32%.

All I have to do to get the right width in XnView MP is to set the zoom percentage to 31%, and, boom, I get ≈ 31.56 with the physical ruler.

So, I do wonder if XnView MP's "real size" is more so the equivalent of Photoshop's "Actual size," that is, a calculation depending on what the computer and monitor are saying, which, indeed can be imprecise.

Anyhoo, "Real size" and "Actual size" remain nonetheless unclear... Maybe "Print size (system calculated)"? IDK.

There doesn't seem to be a uniform approach to using the Y-axis when viewing an individual color channel:

• Histogram
  
  • separate
    XnViewMP, ACDSee, Affinity, GIMP, Photoshop (even in Colors mode)
  • shared
    darktable, DxO
  • not allowed to select individual channel
    CaptureOne, Lightroom, Krita

• Tone Curve
  
  • separate
    CaptureOne, Lightroom
  • shared
    DxO

I would prefer shared Y-axis OR maybe an option to switch it.

ok, so part2 of my problem. I have also large collection of raw images (.CR2 from Canon EOS 400D, .RW from Panasonic Lumix LX-7, and couple of random .DNG or .NEF files).

I would like to do any or all of the following processes:

1. Batch convert them to a format which consumes less space and keeps all info of raw images and is more compatible. What comes to my mind are DNG and JPEG XL. I don't see DNG conversion reducing space consumption, I am wondering that is it more compatible with viewers?

I don't know the bit depth of these camera RAW files, I've tried to find reliable info from many place without finding any. They are not expensive professional cameras so I would guess more likely is 10 or 12 bit than more. In such case AVIF could contain all color info, if it is more than 12-bit then I am not sure.

One large issue I am finding is noise reduction and adjusting levels. I don't want to lose the option to edit these pics later with exposure, level and noise readjustments.


In photo editors (at least Photoshop and Affinity) there seems to be 2 part: A. UI / tools for RAW image processing, B. UI / tools for normal image processing.

noise removal in B seems to be much worse than in A and I don't understand why. Same applies to levels and exposure readjustment.

Can somebody here explain this?


2. Batch convert them to "viewing format" like AVIF by first batch applying RAW noise reduction and levels/exposure adjustment. There are thousands of pics so I can't adjust them manually for everyone. Opinions?

Thane5 wrote: Sun Jan 26, 2025 1:20 pm In german, the setting category "Interface" is incorrectly translated to "Allgemein", which is the word for "General", and already used for the first category. The correct word would be "Benutzeroberfläche".

updated

Thane5 wrote: Sun Jan 26, 2025 1:20 pm Another, possibly related suggestion: I think i would be more intuitive to move the "Settings" option to the "Edit" menu as opposed to "Tools". Most modern software puts it in that category, for example Blender, Affinity Photo and Photoshop.

this is highly subjective
eg, for me, there is only on 'correct' place for app settings - separate Settings menu and:
- Edit (same as File) menu - should be about currently opened file
- Tools menu - about 'tools', instruments that has complex functionality

Thane5 wrote: Sun Jan 26, 2025 1:20 pm Another, possibly related suggestion: I think i would be more intuitive to move the "Settings" option to the "Edit" menu as opposed to "Tools". Most modern software puts it in that category, for example Blender, Affinity Photo and Photoshop.

May I suggest that you post that comment separately in the MP – Suggestions forum section...

In german, the setting category "Interface" is incorrectly translated to "Allgemein", which is the word for "General", and already used for the first category. The correct word would be "Benutzeroberfläche".

Another, possibly related suggestion: I think i would be more intuitive to move the "Settings" option to the "Edit" menu as opposed to "Tools". Most modern software puts it in that category, for example Blender, Affinity Photo and Photoshop.

• Blur
  at 100% has almost the same intense as in Photoshop

however, it worth adjusting other blur filters

• Gaussian Blur
  at max 13x13 in XnViewMP effect equals:
  - 4px in Photoshop (range is 0.1-1000px)
  - 3px in Affinity (range 0.1-100px)
  It would be nice to have larger range as well, eg 0.1-100px

• Maximum/Minimum Blur
  I would update it to match Affinity
  - 0-100px range
  - add Circular checkbox

• Median box (Blur)
  I would update it to match Affinity
  - 0-100px range
  and do something with calculation speed, its too slow

Ante-scriptum: Not sure if this should be reported as a bug, or perhaps a suggestion?

In XnView MP's search function, there is the choice to search by "ratio". Adding that condition presents a dropdown list with numerous common ratios: "1.00 (1:1)," "1.20 (12:10)," and so on.

I noticed however that when I search for 16:9 aspect ratio images, the search function does not pull up images cropped to the 16:9 aspect ratio in post-processing software (either RawTherapee or Affinity Photo in my case). It does however find images that came out of the camera as 16:9, that is, a number of my images taken with a cell phone.

I think this is a mathematical rounding issue. In the dropdown menu, the 16:9 ratio is presented as "1.78 (16:9)".

Very precisely, the 16:9 aspect ratio, converted to a decimal value, is 1.7777∞ (determined simply by converting the ratio to a fraction (16/9) then dividing the numerator by the denominator). So, XnView MP's rounding is correct: brought down to two digits after the decimal, this indeed becomes 1.78.

However, both of the programs I use for post-processing appear to be cropping to as close as they can get to that 1.7777∞.

For example, if I take an image measuring 5553 X 3702 pixels and crop it to 16:9 in either RawTherapee or Affinity Photo, the resulting image measures 5553 X 3124 pixels. Thus, 5553 divided by 3124 gives a decimal ratio of 1.7775288.

One more example: an image measuring 3919 X 2799 pixels and cropped to 16:9 gives an image measuring 3919 X 2205 pixels. Thus, 3919 divided by 2205 gives a decimal ratio of 1.7773242.

I cannot speak for any other post-processing software, but I do hope someone can confirm this in e.g., Lightroom, Photoshop, etc.

Neither of the above cropped images are found by a search for the condition "Ratio" set to "1.78 (16:9)".

EDIT: I did the calculations for a few images that the search does find, e.g.: 2592 X 1456 px, i.e. a decimal ratio of 1.7802197 // 859 X 482 px, i.e. a decimal ratio of 1.7821576 // 3264 X 1832 px, i.e. a decimal ratio of 1.7816593.

So, I'm wondering if it seems as if XnView MP is looking only for images with specifically a two-decimal ratio of 1.78 and thus missing all of those that are close to, but not exactly 1.78.

If indeed this is the case, is there a way to engineer into XnView MP a greater ability to detect 16:9 ratios that are close to but not exactly 1.78? Would it be possible to reset the parameter to read any decimal from, say, 1.777 to 1.787 as 16:9? Definitely, a better math mind than mine is needed!

Thanks in advance for any info you can give!