XnView Software

Environment: Windows 10, version 21H2
XnView MP: 1.7.1, 1.8.3

I take a picture with my DSLR camera while holding it it "portrait" mode (no settings touched on the camera side). I then import the JPEG file to my computer. There I convert my JPEG to JPEG XL in two different ways, both using the most recent reference implementation binaries of JPEG XL provided by one of the developers (I open Command Prompt in the location of JPEG file before I run the command, I also set Path to JPEG XL binaries in computer's Environment Variables before that):
1) lossless recompression — for /r . %f in (*.jpg) do cjxl -j 1 -d 0 -e 10 --brotli_effort=11 "%~f" "%~dpnf._100.jxl"
2) lossly 90% compression — for /r . %f in (*.jpg) do cjxl -j 0 -m 0 -d 1 -e 10 --brotli_effort=11 --num_threads=14 "%~f" "%~dpnf._90.jxl"

This is the result I get in XnView MP's browser window if I have Settings → General → Auto-rotate images according to EXIF orientation turned on:


This is the result I get in XnView MP's browser window if I have Settings → General → Auto-rotate images according to EXIF orientation turned off:


Here's the EXIF data of JPEG.

Here's EXIF data of JPEG XL (both lossless and lossy are the same).

When viewing any of JXL images I get the same orientation as in preview/thumbnail image displayed in browser. That results in wrong orientation of JXL compared to other formats, i.e. JPG: if the auto-orientation is on, the JXL get's rotated-orientated twice in browser/viewer of XnView MP (i.e. 540° instead of 270°), and if auto-orientation is off, the JXL still gets rotated-orientated (i.e. 270° instead of 0°). This makes it challenging to work with folders that contain mixed file types, i.e. JXL+JPG+PNG.

I find current behavior to be quite confusing because I have to constantly switch auto-rotation on and off to manage photos library. I've tried to figure out why that happens but came across only a convoluted explanation in JPEG XL's source code, a brief mention of the kind of sort of the same issue in GitHub comments of the other project and a discussion at Adobe forums that lead to bugfix of Adobe's software.

P.S. I'm sorry this report doesn't follow bug report template closely. I hope this won't make my report obsolete.

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

I am not sure what was issue here as I don't see the images but most recent XNMP version ignores Jpeg XL exif orientation value

I use these scripts to rotate/change orientation:

0:
exiftool -n -orientation=1 -overwrite_original "%INPUTFILE%"

90:
exiftool -n -orientation=6 -overwrite_original "%INPUTFILE%"

180:
exiftool -n -orientation=3 -overwrite_original "%INPUTFILE%"

270:
exiftool -n -orientation=8 -overwrite_original "%INPUTFILE%"


MS Photos respects exif orientation value.

To be fair there are many apps out there that do not yet respect it. Anyway it makes life a bit more complex with JXL images.

golemus wrote: Tue Jul 01, 2025 5:50 am I am not sure what was issue here as I don't see the images but most recent XNMP version ignores Jpeg XL exif orientation value

please send us some sample files

xnview wrote: Tue Jul 01, 2025 6:31 am

golemus wrote: Tue Jul 01, 2025 5:50 am I am not sure what was issue here as I don't see the images but most recent XNMP version ignores Jpeg XL exif orientation value

please send us some sample files

Here you go:

https://1drv.ms/u/c/9ae6b4fc77ec78a7/EW ... g?e=Ghk41q

The JPEG XL format has its own flag for image orientation. libJXL ignores the image orientation information from the EXIF tag.

Source:
https://github.com/libjxl/libjxl/blob/f ... verview.md
under section Metadata versus Image Data.

I don't know how to edit the orientation flag of a JXL image.

WinnieW wrote: Wed Jul 02, 2025 5:17 pm The JPEG XL format has its own flag for image orientation. libJXL ignores the image orientation information from the EXIF tag.

ok. I did some background research of this and I didn't find any way to modify orientation tag inside the jxl data chunk. It seems that there are no tools yet to do that.

Nevertheless even if it is intention of JXL developers to handle orientation it remains to be seen how many years it will take to have proper tools for doing that. While waiting IMO there should be support in programs like XNMP to check the exif:orientation and if it does exist then apply it.

Possibly with a setting such as "respect EXIF orientation of JPEG XL files" somewhere e.g.:

Settings - General
Settings - Browser - Misc
Settings - Formats - Read

Problem in this case: JPEG XL is free to use, however the JXL format specification is not for free.

WinnieW wrote: Fri Jul 04, 2025 9:17 am Problem in this case: JPEG XL is free to use, however the JXL format specification is not for free.

OK. It gives me (IMO) even more reason to add support for EXIF orientation until specs become more accessible to implement rotation/orientation in the way that JXL developers had intended.

Thats not a proper solution, golemus, imo. When it comes to interoperability with other software that handles JXL files as the standard demands.
Maybe ask a developer of JPEG XL where the orientation flag is located in the bitstream?

WinnieW wrote: Sat Jul 05, 2025 7:26 pm Thats not a proper solution, golemus, imo. When it comes to interoperability with other software that handles JXL files as the standard demands.
Maybe ask a developer of JPEG XL where the orientation flag is located in the bitstream?

Problem is that there seems to be yet no apps that can do the orientation in they way they intended (inside the data chunk). At least I didn't find even one after digging for a while. Even libjxl is unable to do that and is it not kind of the standard tool made by the same team who did the JPEG XL standard (at least I have lived under that impression).

xnview wrote: Tue Jul 01, 2025 6:31 am

golemus wrote: Tue Jul 01, 2025 5:50 am I am not sure what was issue here as I don't see the images but most recent XNMP version ignores Jpeg XL exif orientation value

please send us some sample files

Hi Pierre. Here are more sample files of a bit related problem. If I convert file to JXL with magick (imagemagick) and then copy metadata with exiftool, xnmp has issues with these files. Especially reading GPS data, but also reading some other exif data.

Worth noting is that aa.jpg has 90 orientation tag as it is portrait. xnmp and magick do conversion a bit differenlty, xnmp resets orientation tag and makes it 3000x4000px.

magick keeps it 4000x3000px for whatever reason and seems still incapable of copying metadata to JXL. Thus when copying with exiftool metadata xnmp has issues reading the pics. To be honest I am not sure if the issue is in exiftool or xnmp, but as windows photos is able to show gps so I started to suspect xmp.

https://1drv.ms/u/c/9ae6b4fc77ec78a7/ET ... A?e=9iZWnX

golemus wrote: Tue Jul 01, 2025 7:59 am https://1drv.ms/u/c/9ae6b4fc77ec78a7/EW ... g?e=Ghk41q

From libjpegxl

in the case of Exif orientation, this field has to be ignored by applications, since the orientation in the codestream always takes precedence

golemus wrote: Sun Jul 06, 2025 4:42 am Hi Pierre. Here are more sample files of a bit related problem. If I convert file to JXL with magick (imagemagick) and then copy metadata with exiftool, xnmp has issues with these files. Especially reading GPS data, but also reading some other exif data.

Thanks to your detailed description I can reproduce the problem.