Edit: here are the wallpapers if you want to try to reproduce my results: https://drive.proton.me/urls/3JQS48SPQR#TmgLx07up1qg. The heic is a container that includes the light and dark variant. I used magick to split it into two PNGs. I then used the PNGs to create the lossless JXLs and AVIFs.
I really like some of Apple’s wallpapers, but use Linux. Since I care about quality, I took Apple’s official wallpapers and have been converting them from heic to more Linux friendly formats.
Originally, I went for JPEG XL. Though there were two issues bothering me. First, the colors of the image noticeably changed when converting to JPEG XL, though that could an issue with the converter (I’ve been using Switcheroo, though I’m not sure which backend it uses). The second issue is that JPEG XL takes longer to load images than other formats.
I then started experimenting with AVIF and had some pretty good results. First, there’s no color change. Second, at least with lossless conversion, AVIF uses significantly less space. AVIF used 15.8MB, JXL used 24.4MB, and PNG used 36.7MB. I’m not sure if it’s faster than JXL since I’m testing on different, much slower hardware at the moment.
AVIF also, seemingly, I’m not 100% sure, supports progressive decoding: https://github.com/AOMediaCodec/libavif/pull/640
Colors shouldn’t change, sounds like something is wrong.
It also seems odd that loading jxl files would be slow, as I have heard it has excellent performance (I’ve not been able to do any speed testing myself though). Though I wonder if avif is hardware accelerated.
What’s really odd is that you are getting much smaller lossless files out of avif, as pretty much every comparison I have seen shows jxl easily winning when it comes to lossless. Are you sure that you used the actual lossless mode, or did you just set the quality to maximum?
The slowness is more due to a bug in the software decoder my system is using. It has improved over the past year, but to be safe my DE reverted back to regular jpeg: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886
I did confirm they are lossless. I used an app called Identity which lets you compare images easily. Switching between the images while at max zoom showed no change in pixels.
I also updated the post to include a drive link for the files I generated if you wanted to compare.
I played around with the big sur graphic light image. Reduced the size by 50% to make the processing easier, then ran some tests through https://squoosh.app/ I believe squoosh uses an old jxl version, but comparing it with avif in lossless mode, they were both pretty similar in size, with jxl taking a slight lead. I’m not sure why you saw such a big lead for avif on your side. A different image type might show significantly different results though. I think the multicolor gradients (and there is some noise) probably just make it difficult to compress.
> the colors of the image noticeably changed when converting to JPEG XL
I’ve seen this with some embedded profiles and lossy conversions, not on lossless though. You could try removing the profile/all metadata and see if that fixes the conversion? I use the regular libjxl encoder though.I remember trying to do lossles avif but it wasn’t lossless for some reason, as for avif itself, I think it’s better for low quality stuff, but I use jxl for high qualities.
@that_leaflet I agree with the commenters there: it’s weird. I once researched image formats for a website of mine and JPEG XL showed better results in compression. It was slower (as I had to use a WASM-based decoder for browsers which not implement it), but I expected it to improve with time as long browsers implement it. But I can be biased: I used up to 1080p anime images. Also, I wanted progressive loading, which, at that time, AVIF didn’t supported.
Which makes me ponder: since AVIF now supports progressive loading, I guess I can use it in my website and avoid the WASM decoder. :ThinkCatgirl:
