3 ms·

For a library like libjpeg-turbo, it's probably best that it stays in maintenance mode. I mean... it's JPG. It's the traditional lossy image format that everyo

by hannob 3y ago

For a library like libjpeg-turbo, it's probably best that it stays in maintenance mode. I mean... it's JPG. It's the traditional lossy image format that everyone's been using since forever, and that hasn't received any changes. It also shouldn't receive any changes, as its big advantage is its compatibility. If you want something better, you'd use other formats like avif. I'm all for paying open source maintainers, and this guy should receive money so he can continue to fix bugs and do other minor maintenance work. But I don't see why there should be new features in the default jpg library.

regularfry 3y ago
This isn't the default jpeg library. That's libjpeg. In this case, the `jpeg` bit isn't as interesting as the `-turbo` bit. Keeping up with the fastest way to implement JPEG on new architectures and CPUs is worthwhile.
- st_goliath 3y ago
  Depends on what exactly the two of you mean by "default library". It's a fork of libjpeg alright, but from https://en.wikipedia.org/wiki/Libjpeg#History https://en.wikipedia.org/wiki/Libjpeg#History we do get this: > In 2019, libjpeg-turbo became the ISO and ITU endorsed reference implementation for the JPEG format. [13] The paragraph that follows might help to clarify why this happened.
  - regularfry 3y ago
    That's entirely fair, but also worth pointing out that (according to the google groups post) libjpeg-turbo doesn't implement all of the standard. To be even more fair, I don't know if libjpeg does either.
Hello71 3y ago
the email lists many reasons to continue libjpeg-turbo development which are still relevant if a new (let's say better for the sake of argument) image standard exists: > expanding SIMD coverage to new algorithms or instruction sets or CPU architectures, supporting less popular new platforms, improving the APIs, hardening security, improving fuzzer coverage, enhancing the build system, improving automation, etc

by hannob 3y ago

regularfry 3y ago

This isn't the default jpeg library. That's libjpeg. In this case, the `jpeg` bit isn't as interesting as the `-turbo` bit. Keeping up with the fastest way to implement JPEG on new architectures and CPUs is worthwhile.

st_goliath 3y ago
Depends on what exactly the two of you mean by "default library". It's a fork of libjpeg alright, but from https://en.wikipedia.org/wiki/Libjpeg#History https://en.wikipedia.org/wiki/Libjpeg#History we do get this: > In 2019, libjpeg-turbo became the ISO and ITU endorsed reference implementation for the JPEG format. [13] The paragraph that follows might help to clarify why this happened.
- regularfry 3y ago
  That's entirely fair, but also worth pointing out that (according to the google groups post) libjpeg-turbo doesn't implement all of the standard. To be even more fair, I don't know if libjpeg does either.

Hello71 3y ago

the email lists many reasons to continue libjpeg-turbo development which are still relevant if a new (let's say better for the sake of argument) image standard exists: > expanding SIMD coverage to new algorithms or instruction sets or CPU architectures, supporting less popular new platforms, improving the APIs, hardening security, improving fuzzer coverage, enhancing the build system, improving automation, etc