jpegli support about libvips HOT 14 CLOSED

OK, I made an enhancement issue. Thanks!

I'll close this one.

from libvips.

@kurtextrem added some useful notes here: lovell/sharp#4018

from libvips.

Worth noting Jpegli is included in the JXL repo: https://github.com/libjxl/libjxl/blob/main/lib/jpegli/README.md:

When building the parent libjxl project, two binaries, tools/cjpegli and tools/djpegli will be built, as well as a lib/jpegli/libjpeg.so.62.3.0 shared library that can be used as a drop-in replacement for the system library with the same name.

so it might not require extraordinary effort if the "just replace" method is picked (replacing the lib inside libvips), if I understand correctly? It might be valuable to keep mozjpeg around for comparison and upgrade compatibility reasons though (at least temporarily).

from libvips.

If it's just a question of dropping in a binary-compatible jpeg library, then this is really an enhancement for the various libvips build repos.

@kleisauke, shall I made an enhancement issue for the windows build system?

from libvips.

erickguan noted:

A few articles I skimmed through:

• https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
• https://giannirosato.com/blog/post/jpegli/
  The second blog has a few benchmark with commands.

from libvips.

It looks like mozjpeg might still be worth keeping:

I also didn't test every chroma subsampling mode that mozjpeg has to offer, and allowed mozjpeg to subsample chroma automatically - this automatic selection gives it a theoretical advantage over each individual jpegli chroma subsampling mode, but wouldn't allow the encoder to display its breadth of competence like jpegli here. In the end, I wouldn't call this a loss for mozjpeg anyhow - it is clearly not obsolete in any case, and the only scenario in which it clearly lost was the first image test. The overall average & three image average results make a compelling case for mozjpeg overall.
(from https://giannirosato.com/blog/post/jpegli/)

jpegli appears to be better than mozjpeg at q80-100.

from libvips.

@kleisauke, shall I made an enhancement issue for the windows build system?

Sure, that would be great. I'll see if I could add a --with-jpegli build option during the weekend.

from libvips.

Will there need to be a new option to use the XYB colorspace?

from libvips.

I don't think so (but perhaps I'm wrong).

from libvips.

A small question for my understanding: so if jpegli is built and the jpeg libs are replaced at sys level during building of libvips (for linux), or built with --with-jpegli on windows, jpegli would be up and running for anything using libvips?

from libvips.

Yes, it aims to be a drop-in binary-compatible replacement.

It will only replace regular libjpeg for dynamically linked programs, of course. If you have a statically linked libjpeg in there it'll be harder to swap out.

from libvips.

FYI there is new discussion around this after Google did an introduction post about jpegli:

https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

What ended up happening with this issue? I'm confused with the discussion/issue split here in GitHub.

from libvips.

Yeah, I would like to know as well if this is going to be released anytime soon.

from libvips.

See above, while libvips itself (apart from the windows build) doesn't have a specific build option, you can replace the jpeg lib and then build libvips. #3872 (comment)

That's a bit cumbersome, so if you think a better way would be nice, maybe worth opening an issue?

from libvips.