XnView Software

I guess it's a better idea to ask the developers of JPEG XL.

Here: https://github.com/libjxl/libjxl

* Unintentional double post deleted *

A new release of libjxl is in the pipeline. It's just a matter of days.
This will also fix pending bugs in jpegli, incl. bugs related to XYB color space in jpegli.


Just wanted to ask, if this JPEGLI fix has been implemented in the latest version (1.9.5), since I could not find anything in the ...

I guess the WEBP developers use the same settings like JPEG,
set JPEG encoder to 100% quality means lossy compression, too.

The only difference is that WEBP has an additional lossless compression algorithm, which JPEG has not.

It might be confusing to users that a 100% setting doesn't mean ...

A new release of libjxl is in the pipeline. It's just a matter of days.
This will also fix pending bugs in jpegli, incl. bugs related to XYB color space in jpegli.

Wouldn't it be a better solution to ask the developers of JPEG XL how to modify the image orientation of existing JXL files instead of doing such a hackish approach?

Anybody is allowed to ask questions on the github plattform.

https://github.com/libjxl/libjxl/issues

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

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?

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?

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 in this case: JPEG XL is free to use, however the JXL format specification is not for free.

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/f88745497118727f861cb00887cadcb395d10f1c/doc/format_overview.md
under section Metadata versus Image Data.

I don't know how ...

I noticed that.
Maybe the priority isn't high, or the developers assume that JPEG files with XYB are considered experimental and only a few people are using that coding option.
Anyway, in the meantime, until a proper bugfix is in the official code of jpegli,
a quick fix might be disabling color ...

CMYK color space is primarily of interest for printing images. For displaying CMYK images on a monitor they have to be converted to RGB color space for that purpose.

Are you sure that JXL (lossy) is always 444?
Raw 420 data consumes 60% of 444 data space. Seems akward if JXL didn't have opportunity to use this.

JPEG XL does use XYB color space by default. 420 subsampling is only defined for YUV color space.
Only legacy JPEG does use YUV color space by ...