3 ms·

>> 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 fu

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

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