Disable libjxl lossless mode for float16

[kiwixz]

Closes #17487.

As discussed in the issue, libjxl lossless encoding of float16 is actually broken.
This patch disables the real lossless mode of libjxl, while still asking for a distance of 0 (basically lossless).

It didn't feel useful to mention this in tooltip of the quality slider.

[kmilos]

This patch disables the real lossless mode of libjxl, while still asking for a distance of 0 (basically lossless).

Although a neat workaround, not 100% sure this is the way to go, there might be other side effects of settings distance to 0 here (IIRC it's been mentioned that could be considerably worse than true lossless mode for file size and encoding time, especially if original color space is kept)? It'd be ideal if we just totally disable this for fp16...

[kiwixz]

Tested on the good old Debian logo:

quality	color profile	size
100 (distance 0)	(original)	27K
100	original	19K
100	internal	11K
99	original	16K
99	internal	8.5K
98	original	15K
98	internal	7.8K

Looking at the pixels samples, the distance 0 is indeed closer to original.
I think we should give the best possible quality when user cranks the slider to the right, regardless of the size.
We would really give lossless if this was possible but it's not.

Now the next question could be: "Should lossless be optional for quality 100?", but that's out of scope for this PR.

[TurboGit]

I feel that the discussion is not fully resolved, should this be accepted or a better way found? In other word what is the status of this PR?

[kmilos]

"Should lossless be optional for quality 100?", but that's out of scope for this PR.

IMHO not, as that was the design premise and what the tooltip promised/promises...

Until this is fixed upstream, I'd still rather just totally skip fp16 at q=100/d=0 and limit this to q=99 (which is already ridiculously high anyway for the lossy mode)...

[kiwixz]

Until this is fixed upstream, I'd still rather just totally skip fp16 at q=100/d=0 and limit this to q=99 (which is already ridiculously high anyway for the lossy mode)...

It's sensible, but then we need to make a special case for quality=100 to specify uses_original_profile which makes float16 ever more diverging from all other formats... It's a lot of effort for an edge case that virtually nobody will encounter; upstream is plain broken and nobody really noticed.
On the other hand this trivial patch sets distance to 0 and you end up with a big file, but as you say q=99 is already ridiculously high anyway so I does not make sense to waste more time on this.

[kmilos]

How about this?

1. Let's wait w/ this until the code freeze, in the hope something happens upstream and we maybe at least get a new JPEGXL_NUMERIC_VERSION we can use to gate this hack with. If not, I'm ok(-ish) merging as is at that point (pragmatically better than spending effort on excluding this mode properly indeed, or reverting lossless float support altogether).
2. In any case, we should add a line to known issues in the release notes, something like "Due to an upstream issue, exporting JPEG XL in 16-bit float at quality 100 (distance 0) is not truly/mathematically lossless [currently | when using libjxl <= 0.x.y]"

[kmilos]

I don't think we can punt this to 5.2, it crashes dt currently?

[kiwixz]

I rebased on master and mentioned the problem in the release notes.

Considering there is no sign of life in the relevant issues upstream, I think we should just merge this now.