JXL -- option to specify distance and not quality

[Tokariew]

Is your feature request related to a problem? Please describe.

Distance option allow for more granular setting output quality when exporting to jpeg-xl i would like to see option to switch to using distance instead of quality switch when exporting to JXL

Describe the solution you'd like

Add option in preferences to switch between distance and quality when exporting to jxl

Alternatives

Option in export module to switch between distance and quality

Additional context

None…

[gi-man]

The quality setting is just converted to distance in libjxl via a formula. The resulting image is the same. Most of the photographic users are familiar with quality percent. Having to explain Butteraugli is not ideal to our users that are not interested in math. How about we add some info into the tooltips/manual? 90% = 1.0 distance, 80% = 1.9 distance, 100 = zero/lossless.

I keep my exports at 1.0 (90%) since it is visually identical. If I want a really small photo size, 80 would be fine in my opinion, but nothing below that for photos. For other items like web art, other values make more sense.

[Tokariew]

with quality i have 10 option between lossless and visually lossless… with distance i have at least 95 (looking at distinct hashes from 0.01 to .99 )

I don't want to change quality option to distance, only add option to switch to distance if you know what are you doing. I don't propose to make distance default or only option

[kmilos]

with quality i have 10 option between lossless and visually lossless… with distance i have at least 95

Can you please provide an example, i.e. a real image artifact (not a hash, nor a synthesized test) that demonstrates that the quality steps 90-99 are not sufficiently fine enough to achieve a satisfactory output?

[victoryforce]

Well, I really don't understand why you need even one extra step between a visually lossless and a mathematically lossless compression. Visually lossless compression, by definition, produces an image that the human eye, under normal viewing conditions, cannot distinguish from the original. So by definition such an image cannot contain visible artifacts and by definition there is no point in intermediate gradations between visually lossless and mathematically lossless compression.

[gi-man]

I was wrong. We seem to do the math in our dt code.

darktable/src/imageio/format/jxl.c

Lines 187 to 191 in e3bd787

	const float distance
	#if JPEGXL_NUMERIC_VERSION < JPEGXL_COMPUTE_NUMERIC_VERSION(0, 9, 0)
	= MIN(params->quality >= 30 ? 0.1f + (100 - params->quality) * 0.09f
	: 6.24f + powf(2.5f, (30 - params->quality) / 5.0f) / 6.25f,
	25.0f);

I agree with kmilos. I dont see the need to go to XX.X quality, but open to see examples.

[kmilos]

We seem to do the math in our dt code

That's for older libjxl versions, as the #if branch shows. For a while now there is a libjxl provided API for the conversion (and also already used a few lines below): https://github.com/libjxl/libjxl/blob/15c547544296c29a2da931e9112e3c45e3972ef6/lib/include/jxl/encode.h#L1497

[victoryforce]

I think it would be better to close this issue for now, since it seems that the OP abandoned it and will not comment on it anymore. Especially since this is not a bug report, this is a feature proposal and I still don't see any arguments that this proposal makes sense.

[Tokariew]

have a nice day, and thank you for darktable