Optional dithering in cjpegli and djpegli

[j7nj7n]

Standard decoders can't accurately reproduce the high precision data in JPEG files created by cjpegli. Most software doesn't have the Li decoder and will never get it. A file created from undithered 16-bit input with Li has more banding than one produced by jpeg-turbo from 8-bit with dither. Perhaps the tool could apply noise-shaping at the correct stage. From what I gather, dithering the RGB input helps but isn't optimal because truncation occurs later in the YCbCr domain. Some colors may be reduced to around 6 bits and are insufficiently dithered. But green and grey doesn't need as much dither.

When decompressing with djpegli to 8-bit depth, dithering could also be applied. An intermediate step to 16-bit gives a slightly better result.

Dithering reduces precision and compression ratio, so this should be an optional switch. It should be "noise-shaping" only when there is a quantization error so that pure black and white stay unchanged and compress well. Normally only a fraction of an image consists of a gradient, and the relative compression loss would be less.

Hopefully the images are not transcoded. They should be viewed against a dark background.

gradient_16 - source:

gradient_16_LI - jpeg (signifcant banding in browser and viewers):

gradient_16_LI - decoded to 8-bit:

gradient_16_LI_Ps_dither - decoded to 8-bit with dither (compression suffers):

gradient_8_dither_irfan - standard jpeg-turbo: