XnView Software

Pierre recently mentioned that XnView uses libjpeg's -dither fs and -dct fast switches for loading/decoding JPEG files.

-dither fs uses Floyd-Steinberg dithering in color quantization which “usually produces the best results”:

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.

I support and very wait this upgrade )

My tests (i7-9750H):

1. Download jpegsr9f.zip and extract testorig.jpg (progressive DCT with 2×2 chroma subsampling) from the archive.
2. Download jpg9eexe.zip and extract djpeg.exe from the archive.
3. Run djpeg -bmp -dct fast -dither fs testorig.jpg dctfast.bmp.
4. Run djpeg -bmp -dct float -dither fs testorig.jpg dctfloat.bmp.
5. Compare dctfast.bmp and dctfloat.bmp:
   • Beyond Compare
   • DiffImg
   • ImageComparator
   • img2go.com
   • PSNR

I converted testorig.jpg with XnView to BMP and was expecting dctfast.bmp and xnview.bmp to be identical, but they are not

Because in XnViewMP all also as in ACDSee 3.0 with release date 09.12.1999 namely full absent dither for JPEG format if we reading JPEG files )

XnTriq
Thank you for Diffimg ) this very comfortabling application )

Xn User wrote: Tue Feb 18, 2025 10:05 amXnTriq
Thank you for Diffimg ) this very comfortabling application )

This is what I very wait ) I want when I can refuse of ACDSee Pro ) now to me keep hold only quality decode JPEG )

See issue for current status and some details.

Thanks for considering, Pierre!

I wait for test , I want evaluate quality of dither )

Another option that might be worth investigating is jpegli decoding for JPG files, in other words the decoder of jpegli.

The developers of jpegli claim higher quality decoding of jpeg files.

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.

https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html wrote:In this comparison we limited ourselves to comparing the encoding only, decoding was always performed using libjpeg-turbo.

PS: https://lobste.rs/s/oq7wit/introducing_ ... peg_coding

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.

https://github.com/google/jpegli#decoder-improvements

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.

Thanks, WinnieW!
I missed that

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

This problem is supposed to be fixed in XnView MP 1.8.7. Please check and confirm the bug fix here.