3 ms·

> add incompatible, non-standard format extensions and change the down-/upsampling algorithm for images with chroma subsampling such that it tends to introduce

> add incompatible, non-standard format extensions and change the down-/upsampling algorithm for images with chroma subsampling such that it tends to introduce additional artefacts, because when decoding e.g. a classic 4:2:0 subsampled image (i.e. chroma resolution is half the luma resolution both horizontally and vertically), each subsampled 8x8 chroma block is now upscaled individually to 16x16 for the final image, which can and does introduce additional artefacts at the boundaries between each 16x16 px block in the final image. But the current libjpeg maintainer insists on that new algorithm because it is mathematically more beauftiful…

phkahler 3y ago
>> But the current libjpeg maintainer insists on that new algorithm because it is mathematically more beauftiful… Ugh. That always has to take a backseat to functionality and usefulness. Well, if you want to serve users and not just yourself. I'm still in the thinking phase of a major rewrite of a big piece of code that will make it bug-free, but it will likely be very ugly due to a large number of cases/variations to handle. I'll spend a little more time looking for an elegant simplification, but it has to be done one way or the other to fix the ecisting bugs.
- iggldiggl 3y ago
  Supposedly the advantage is that the new scaling algorithm (via a Discrete Cosine Transform) is perfectly reversible (other than the data loss by introduced by the initial downscaling of course) – in practice I found that looking at the whole compression/decompression pipeline, a current libjpeg (using DCT scaling) still takes a number of iterations of repeated compression and decompression to converge to a stable image, i.e. not really different from both an older version of libjpeg itself, respectively libjpeg-turbo (both of which still use bilinear scaling or something like that for subsampling). The additional artefacts between subsampling blocks introduced by DCT scaling on the other hand were clearly visible if you knew to look for them. (They're admittedly not super-massive, but under certain circumstances they are noticeable, which is how I stumbled across that topic in the first place – it turned out when I finally switched to a current version of my favourite image editor, it had in the mean time upgraded from an older libjpeg version to a newer version that was using DCT scaling. Thankfully the authors of that editor were actually willing to switch to libjpeg-turbo – somewhat ironically without the real "turbo" bits because they couldn't get the assembler bits working with their build system, so not much of a speed-up, but at least it got rid of the decoding artefacts for subsampled images.)

phkahler 3y ago

>> But the current libjpeg maintainer insists on that new algorithm because it is mathematically more beauftiful… Ugh. That always has to take a backseat to functionality and usefulness. Well, if you want to serve users and not just yourself. I'm still in the thinking phase of a major rewrite of a big piece of code that will make it bug-free, but it will likely be very ugly due to a large number of cases/variations to handle. I'll spend a little more time looking for an elegant simplification, but it has to be done one way or the other to fix the ecisting bugs.

iggldiggl 3y ago
Supposedly the advantage is that the new scaling algorithm (via a Discrete Cosine Transform) is perfectly reversible (other than the data loss by introduced by the initial downscaling of course) – in practice I found that looking at the whole compression/decompression pipeline, a current libjpeg (using DCT scaling) still takes a number of iterations of repeated compression and decompression to converge to a stable image, i.e. not really different from both an older version of libjpeg itself, respectively libjpeg-turbo (both of which still use bilinear scaling or something like that for subsampling). The additional artefacts between subsampling blocks introduced by DCT scaling on the other hand were clearly visible if you knew to look for them. (They're admittedly not super-massive, but under certain circumstances they are noticeable, which is how I stumbled across that topic in the first place – it turned out when I finally switched to a current version of my favourite image editor, it had in the mean time upgraded from an older libjpeg version to a newer version that was using DCT scaling. Thankfully the authors of that editor were actually willing to switch to libjpeg-turbo – somewhat ironically without the real "turbo" bits because they couldn't get the assembler bits working with their build system, so not much of a speed-up, but at least it got rid of the decoding artefacts for subsampled images.)