XnView Software

Hey everyone,

I came across this topic through a link in a post on the Affinity Forum https://creofora.com — they were discussing the same question about the preview in XnView MP not showing up yet. Glad to see it’s already being worked on here!

Also, just a quick heads-up — Affinity Studio is now free to download an use!
You can grab it here: https://www.affinity.studio/

Done

please send us some sample files

Well, that should hopefully make it simpler to implement thumbnail support. I've added 'af' to my custom extensions list, but it doesn't change preview or not.

Camva claimed the new format was not backward compatible. Renaming *.af *.afphoto has no impact on loading the file in Affinity, either. Apparently the app must be reading the internal file header to determine its format, not relying on the extension.

I don't think there has changed a lot under the hood, since if you rename the .af file to .afphoto, XnView is still able to show the embedded preview thumbnail.

In March of last year Canva acquired Serif and their products: Affinity Photo, Designer and Publisher. XnView supports the embedded preview thumbnail images in .afphoto files (from Affinity Photo 2), but now Canva has released Affinity 3 which replaces all three Serif Affinity apps. The new file format has an "af" extension and we only get icons in XnView with no metadata:


Those are the new and old versions of the same file.

I understand it'll take a while to support the new format, I just wanted to mention it. I have no idea how / where to get enough specs to implement reading these files enough for XnView's uses.

I'm just flagging this as I know it will be eventually addressed in a future release.

With the release of the new Affinity suite the file format has changed from individual files per program i.e afphoto, afpub and afdesign to a single file format with the .af file externsion. As expected the new file format does not preview in xnviewmp.

I suspect that this issue is all about what the raw development software does itself.

The preview embedded in a .afphoto file is indeed small, and that's surely the case for acdsee as well. Adobe must embed a full-size preview in their .psd files.

I think those previews are the only thing xnview could access, short of reverse engineering the files of the various raw processors...

I have the same problem with affinity photo2 files. They are displayed only smallsized in the View mod as well as in slideshow. I hoped to be able to use XnviewMP also for a quick slideshow. but this is not okay now. As to the other posts in this section, I hope this will be solved somehow some. (I am getting homesick for Lightroom as bit now)

p.s. A tutorial on how to use all the options of the catalog database settings would be much appreciated. It is very confusing still!

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).