XnView Software

xnview wrote: Sun Jul 06, 2025 1:41 pm

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

I read that also somewhere. Anyway until there are tools to read and modify standard JXL orientation IMO it might? be good idea to have this setting but so that it is disabled as default and it is clearly mentioned below the setting or in tooltip that it changes JXL rendering to non-standard.

"respect EXIF orientation of JPEG XL files (NON-STANDARD)"
(enabling this setting is not standard JXL behaviour but a temporary setting to allow user to rotate pics losslessly until there are tools to read and write standard JPEG XL orientation. We recommend to re-process all jxl files with exif orientation when tools for processing standard jxl orientation become available. Keep in mind that many apps ignore jxl exif orientation)

xnview wrote: Sun Jul 06, 2025 1:41 pm 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

Now I found this:

https://libjxl.readthedocs.io/en/latest ... rientation

Can these values be read and/or modified by xnmp through libjxl...?

There is one question that puzzles me. Why not encode the image with the desired orientation in first place?
Why all the hazzle with image orientation tags?

Why not rotate the image accordingly before encoding to JPEG XL?

WinnieW wrote: Sun Jul 06, 2025 8:06 pm There is one question that puzzles me. Why not encode the image with the desired orientation in first place?
Why all the hazzle with image orientation tags?

Why not rotate the image accordingly before encoding to JPEG XL?

I think I explained this in some other thread but if you have collection of thousands of pics there is always likelyhood that there are some pics among them that have wrong orientation and you had not noticed it. Then you batch convert the collection and possibly years later notice that there are wrongly oriented images that you either hadn't noticed or forgot to fix them and you would like to fix orientation without losing quality.

Shrinking a collection to smaller jxl or avif collection (if you know what you are doing) is max 30 minutes to initialize and test batches and then you let the computer run overnight, or longer and it is ready.

Browsing through lets say 40k images that I have for ones that have wrong orientation could take much much longer.

Wouldn't it be better to wait with mass conversations to JXL until the JPEG XL encoder is finalized?

Are you talking a developer into implementing a feature that is non-standard just to match your personal work flow?

WinnieW wrote: Sun Jul 06, 2025 9:34 pm Wouldn't it be better to wait with mass conversations to JXL until the JPEG XL encoder is finalized?

I was living under the impression that it is already finalized.

Are you talking a developer into implementing a feature that is non-standard just to match your personal work flow?

Absolutely not.

JPEG XL picture orientation is creating a lot of confusion and unexpected behaviour perceived by users. I am not the one who created this topic and if you google you will find similar ones from elsewhere as well.

I just suggested a potential solution to deal with it.

golemus wrote: Mon Jul 07, 2025 2:07 am I was living under the impression that it is already finalized.

The format itself is finalized, but the encoder and decoder are still under development... JPEG XL is considered to be in a pre-release state, atm.
It's in a "use at your own risk" state of development. I would check every single JXL image for possible damage.