4 ms·

There are probably a ton of projects that depend on libjpeg-turbo, but the first thing that comes to mind are browser vendors. It's probably fair to say that mo

There are probably a ton of projects that depend on libjpeg-turbo, but the first thing that comes to mind are browser vendors. It's probably fair to say that most jpegs are viewed in web browsers. They should really just chip in, or even formally employ the author to just continue working on this library.

st_goliath 3y ago
FWIW, Mozilla has been maintaining their own fork for quite a while now[1] But AFAIK most Linux Distros have been using libjpeg-turbo as a drop-in replacement for libjpeg, after some drama in ~2010 where libjpeg came under new management, decided to break ABI/API several times over and add incompatible, non-standard format extensions[2]. [1] https://github.com/mozilla/mozjpeg https://github.com/mozilla/mozjpeg [2] https://en.wikipedia.org/wiki/Libjpeg#History https://en.wikipedia.org/wiki/Libjpeg#History
- iggldiggl 3y ago
  > 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.)
- planede 3y ago
  Interesting, however I found this in the mozjpeg readme: > MozJPEG is a patch for libjpeg-turbo. Please send pull requests to libjpeg-turbo if the changes aren't specific to newly-added MozJPEG-only compression code. This project aims to keep differences with libjpeg-turbo minimal, so whenever possible, improvements and bug fixes should go there first. So they still rely on upstream development of libjpeg-turbo. Unless the readme is out of date and they don't bother syncing with libjpeg-turbo now.
  - bscphil 3y ago
    Right, it's not a proper fork. It's actually just a static set of patches that improve the compression ratio in libjpeg-turbo but can't be upstreamed, for reasons.
- muizelaar 3y ago
  Firefox doesn't use mozjpeg, it just uses libjpeg-turbo: https://searchfox.org/mozilla-central/source/media/libjpeg https://searchfox.org/mozilla-central/source/media/libjpeg Mozilla has sponsored libjpeg-turbo in the past: https://libjpeg-turbo.org/About/Sponsors https://libjpeg-turbo.org/About/Sponsors
dzogchen 3y ago
Although MapLibre Native is primarily a vector-tile based maps renderer, we also support raster images and we depend on libjpeg-turbo for it.

st_goliath 3y ago

FWIW, Mozilla has been maintaining their own fork for quite a while now[1] But AFAIK most Linux Distros have been using libjpeg-turbo as a drop-in replacement for libjpeg, after some drama in ~2010 where libjpeg came under new management, decided to break ABI/API several times over and add incompatible, non-standard format extensions[2]. [1] https://github.com/mozilla/mozjpeg https://github.com/mozilla/mozjpeg [2] https://en.wikipedia.org/wiki/Libjpeg#History https://en.wikipedia.org/wiki/Libjpeg#History

iggldiggl 3y ago
> 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.)
planede 3y ago
Interesting, however I found this in the mozjpeg readme: > MozJPEG is a patch for libjpeg-turbo. Please send pull requests to libjpeg-turbo if the changes aren't specific to newly-added MozJPEG-only compression code. This project aims to keep differences with libjpeg-turbo minimal, so whenever possible, improvements and bug fixes should go there first. So they still rely on upstream development of libjpeg-turbo. Unless the readme is out of date and they don't bother syncing with libjpeg-turbo now.
- bscphil 3y ago
  Right, it's not a proper fork. It's actually just a static set of patches that improve the compression ratio in libjpeg-turbo but can't be upstreamed, for reasons.
muizelaar 3y ago
Firefox doesn't use mozjpeg, it just uses libjpeg-turbo: https://searchfox.org/mozilla-central/source/media/libjpeg https://searchfox.org/mozilla-central/source/media/libjpeg Mozilla has sponsored libjpeg-turbo in the past: https://libjpeg-turbo.org/About/Sponsors https://libjpeg-turbo.org/About/Sponsors

dzogchen 3y ago

Although MapLibre Native is primarily a vector-tile based maps renderer, we also support raster images and we depend on libjpeg-turbo for it.