Unclear documentation for encoder options quality and effort

[Enet4]

While tinkering with the encoding APIs in zune-image, I found an oddity in the type EncoderOptions. Documentation for the getter and setter of effort is missing, and there are claims in method get_quality that the quality option also affects effort when doing lossless encoding:

Lossy

Higher quality means some images take longer to write and are big but they look good

Lower quality means small images and low quality.

Lossless

High quality indicates more time is spent in making the file smaller

Low quality indicates less time is spent in making the file bigger

It would be great if the documentation of the encoder options answered these questions:

• Is there a universally accepted range of values for effort? Should we also provide a number in the range 0..100?
• If an encoder supports mathematically lossless encoding, does quality = 100 imply lossless encoding? Or is there another way to signal that the encoding is intended to be lossless?
• Does quality still affect the encoding effort when doing lossless encoding, or is this part of the documentation outdated?

[etemesi254]

Hi, apologies for the very very late reply.
I believe this is in tandem with the zune-jpegxl encoder

The jpeg-xl encoder is based on https://github.com/libjxl/libjxl/blob/c6355600c5932e3a9f1b95a4cadfa9b718fbec8f/lib/jxl/enc_fast_lossless.cc (libjxl fast lossless encoder) with the SIMD part stripped out, so the effort is directly tied to that, effort here means that we increase grid search space for sample collection.

To answer your question though

Is there a universally accepted range of values for effort? Should we also provide a number in the range 0..100?

No there should be though

If an encoder supports mathematically lossless encoding, does quality = 100 imply lossless encoding? Or is there another way to signal that the encoding is intended to be lossless?

I haven't gotten to the part where I have both a lossless and a lossy encoder for one format (that would be either webp or jxl), but it is usually better to have an explicit switch for such things, quality =100 is not equal to lossless when one chooses a lossy encoder, so separate them

Does quality still affect the encoding effort when doing lossless encoding, or is this part of the documentation outdated?

No it should not, this is used for the lossy encoders, specifically jpeg

[Enet4]

Thanks for the reply. It was not originally clear that zune-jpegxl only supported lossless encoding exclusively (it was clear that it offered lossless encoding, but not that it did not provide other forms of encoding, but maybe I extrapolated a bit too hard).

Is there a universally accepted range of values for effort? Should we also provide a number in the range 0..100?

No there should be though

If an encoder supports mathematically lossless encoding, does quality = 100 imply lossless encoding? Or is there another way to signal that the encoding is intended to be lossless?

I haven't gotten to the part where I have both a lossless and a lossy encoder for one format (that would be either webp or jxl), but it is usually better to have an explicit switch for such things, quality =100 is not equal to lossless when one chooses a lossy encoder, so separate them

Is there something the community can do to assist in the process of uniformizing the quality/lossless/effort parameters?