libvips has pretty good AVIF support already, so I don't see that as a blocker to JXL. I plan to have a look at this before 8.11, though of course I don't know how much work it'll be.

the underlining AV1 does have HW decoding in Apple's M1

The M1 does not support hardware AV1 decoding, but it performs decently in software. RDNA2, Ampere, Tiger Lake, Rocket Lake, and some ARM SoCs (although none from Apple or Qualcomm) do support hardware AV1 decoding.

Ah that was a debug build, it's much quicker in release:

$ time ./encode_oneshot x.pfm x.jxl 
real	0m0.456s
user	0m1.041s
sys	0m0.391s

About 10x slower than libjpeg-turbo.

$ time vips copy x.ppm x.jpg
real	0m0.047s
user	0m0.089s
sys	0m0.009s

Yes, my tests line up with that -- very fast (compared to avif anyway), and great compression.

It does use a lot of memory, on the downside, but improvements are supposed to be coming. I would guess it'll be another year or so of work to get to production.

A lot of memory for compression only (like FLAC) or decompression requires the same amount??

My understanding is that the tiers set the types of decompression that the compressor will target. JXL has several decompression systems, some slow and some fast, and compressors can use a mix of them to try to recreate the image.

No, not yet.

Am I correct in understanding that libvips supports JXL through the libjxl library? If that is the case, is it a matter of adding the argument to libvips and then passing it through as a parameter to libjxl?

libvips only exposes a subset of the libjxl encoding options. You can see the API we support here:

https://www.libvips.org/API/current/VipsForeignSave.html#vips-jxlsave

I'd be a little cautious -- JXL is still not stable enough for production use (IMO) and implementing JXL in TIFF would mean our TIFF loader could no longer be trusted with internet data.

A PR for this would be great, but it would have to be off by default for now.

I have just tried this on the latest master and see that it still doesn't work. This would be welcomed. I have had trouble with moving metadata from TIFF to JXL no matter what I have tried, and moving from TIFF container to TIFF container would likely solve this for me while offering most of the space savings associated with lossless JXL.

Yes, those developments have been extremely disappointing to me. Thanks for the links.

Nice! I've been waiting for lossy 16-bit per channel support, looks like it's coming soon.

Hello @sergeevabc,

We wrote the libvips jxl interface code back in the libjxl-0.4 days (I think?), and the libjxl API has evolved since then. We have some work on this bit of libvips scheduled for libvips 8.16, see eg.:

#3712

@sergeevabc You're mixing up lossless transcoding and lossless encoding.

cjxl image.jpg image.cjxl.jxl does lossless transcoding from JPEG to JPEG XL. This allows you to create a JPEG XL image from JPEG data without decoding it. Since the data is not decoded and encoded back, there are no additional losses. And since cjxl doesn't need to decode/encode the image, it converts it to JPEG XL momentarily.

vips copy image.jpg image.vips.jxl --lossless does lossless encoding. Vips works with raw pixels, so it needs to decode an image before doing stuff with it. So, it can't losslessly transcode JPEG to JPEG XL. At least, it would require a lot of work and a huge amount of duct tape to make it do so. Decoding/encoding of an image takes some time, especially lossless encoding enabled with the --lossless flag. And of course, lossless encoding produces huge files.