[adam-ce]

when we tried to adopt GPU jpeg for our project, I realised that it has slightly worse encoding quality compared to jpeg turbo. so I tasked Claude to look for and fix the issue. codex conducted a review.

I also have some other fixes, but I don't know what your LLM policy is, so I'm starting with this one. I'm happy to iterate on it, you can take it or close it :)

this is the llm summary:

Summary

Improve JPEG colour fidelity by filtering chroma during encoding and decoding.

• Encoder: replace point sampling with averaging over the subsampling window.
• Decoder: replace sample replication with triangle interpolation for 4:2:0,
  4:2:2 and 4:4:0 chroma when producing full-resolution output.
• Enable both filters by default, with independent options to restore the
  previous behaviour.

Evidence

Measured on four real 4096×4096 RGB orthophoto tiles at quality 95, 4:2:0,
using an RTX 4090. RGB PSNR is measured against source pixels.

• Full GPUJPEG encode/decode improves by 0.64–1.39 dB, averaging 1.01 dB
  across the four tiles—equivalent to 14–27% lower mean squared error.
• The quality deficit relative to libjpeg-turbo shrinks from 0.67–1.44 dB
  to 0.03–0.06 dB.
• Encoder-only improvement, using libjpeg-turbo for decoding: 0.17–0.49 dB.
• Decoder-only improvement, using identical libjpeg-turbo JPEGs: 0.32–0.70 dB.
• Encoded files are approximately 0.4–0.6% smaller.
• Added kernel time is approximately 0.01 ms each for preprocessing and
  postprocessing per 4096×4096 image.

CTest passes all three suites. CUDA memcheck reports no errors or leaks,
and targeted chroma-kernel racecheck reports no hazards. Tests cover
sampling layouts, odd dimensions, padded input, default-on behaviour,
and toggling the filters between calls.

[MartinPulec]

Thanks, I've pushed several changes on top of the changes, namely:

1. I rewritten the encoder to use the averaging unconditionally - as already noted by 8be6ab0 - it is compulsory in JFIF. This also allowed to more tightly coupling and the encoder is even faster than before when using sub-sampling. This is not entirely surprising, however, because as now eg. for 4:2:0 one thread processes 2x2 px, it amortizes the thread overhead better. So also:
2. The option is deprecated on encoder as it is always on (when trying to set to off it returns false).
3. One of test cases in test_chroma_filter.c ceased to work (when enc/dec disabled) because disabling for the decoder is no more possible. So for the test_case()=0, just the decoder opt is tested.

Decoder is entirely untouched - I believe that encoder/decoder (opt) is not symmetric, actually. The encoder AFAIK must interpolate (mandated by JFIF). The decoder on the other side may copy the sample (as the chroma information is already partially lost) and the smoothing can be considered optional (also djpeg has -nosmooth option, that in my opinion should do exactly what -O dec_opt_chroma_filter=0 does for GJ).

Another observation - if encoding with libjpeg(-turbo), -dct float should be added to behave more like GPUJPEG does (for eg. comparison) otherwise libjpeg produces slightly better quality (I believe that it slightly less quantized at the same Q given by the integer division but not sure).