https://www.ijg.org/files/jpegsr9f.zip → usage.txt → DJPEG DETAILS wrote:-dither fs Use is slow but usually produces the best results dithering in color quantization. -dither ordered Use ordered dithering in color quantization. -dither none Do not use dithering in color quantization. By default, Floyd-Steinberg dithering is applied when quantizing colors; this is slow but usually produces the best results. Ordered dither is a compromise between speed and quality; no dithering is fast but usually looks awful. Note that these switches have no effect unless color quantization is being done. Ordered dither is only available in -onepass mode.
-dct fast, however, is the least accurate DCT method:
https://www.ijg.org/files/jpegsr9f.zip → usage.txt → DJPEG DETAILS → Switches for advanced users wrote:-dct int Use integer DCT method (default). -dct fast Use fast integer DCT (less accurate). -dct float Use floating-point DCT method.
The float method is very slightly more accurate than the int method, but is much slower unless your machine has very fast floating-point hardware. Also note that results of the floating-point method may vary slightly across machines, while the integer methods should give the same results everywhere. The fast integer method is much less accurate than the other two.
https://www.ijg.org/files/jpegsr9f.zip → usage.txt → HINTS FOR DJPEG wrote:"-dct fast" and/or "-nosmooth" gain speed at a small sacrifice in quality. When producing a color-quantized image, "-onepass -dither ordered" is fast but much lower quality than the default behavior. "-dither none" may give acceptable results in two-pass mode, but is seldom tolerable in one-pass mode.
If you are fortunate enough to have very fast floating point hardware, "-dct float" may be even faster than "-dct fast". But on most machines "-dct float" is slower than "-dct int"; in this case it is not worth using, because its theoretical accuracy advantage is too small to be significant in practice.
Please add (an) option(s) in Tools → Settings… → Formats → Read → JPEG for users like me who prefer quality/accuracy over speed.
WinnieW wrote: Mon Feb 24, 2025 12:15 pmThe developers of jpegli claim higher quality decoding of jpeg files.
… if encoded with Jpegli.
https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html wrote:10+ bits. Jpegli can be encoded with 10+ bits per component. Traditional JPEG coding solutions offer only 8 bit per component dynamics causing visible banding artifacts in slow gradients. Jpegli's 10+ bits coding happens in the original 8-bit formalism and the resulting images are fully interoperable with 8-bit viewers. 10+ bit dynamics are available as an API extension and application code changes are needed to benefit from it.
Yeah,
but the developers of jpegli claim their own jpeg decoder use floating point calculation and conversion to integer only once, so there are fewer rounding errors, which means possibly more accuracy.
I compared decoding existing jpeg files, older than jpegli itself, so they can't be compressed by jpegli,
with both libjpeg and jpegli.
The jpeg files decoded with jpegli has more colors than the same jpeg decoded with libjpeg. To my eyes there is near to no visible difference between them though.
So I'm not sure if the difference is significant enough.
Support for 16-bit unsigned and 32-bit floating point output buffers.
Non-zero DCT coefficients are dequantized to the expectation value of their respective quantization intervals assuming a Laplacian distribution of the original unquantized DCT coefficients.
After dequantization, inverse DCT, chroma upsampling and color space conversions are all done in floating point precision, the conversion to integer samples happens only in the final output phase (unless output to floating point was requested).
I support your suggestion to add an option for Jpegli decoding.
