av1-avif VS brunsli

The article is about avif not webp. Note the editors for the AOM avif specification don't even include Google https://aomediacodec.github.io/av1-avif/

This reminds me of something similar from the guy who implemented AVIF in Firefox. He gives a talk about the implementation [1] where he talks about the CLAP privacy problem. Basically the spec adds a field that allows for cropping of the image, but the binary file would still contain the original. This would lead users to believe some image data was deleted when it really wasn't. I always thought he spent a lot of time and effort on this for little gain, but now I'm starting to think it was worth his effort.

[1]: https://youtu.be/BUkRlfkv2D8?t=2199

And the related GitHub issue: https://github.com/AOMediaCodec/av1-avif/issues/188

So actually the same images I linked above are in the AOMediaCodec repo as well, under Link-U: https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Link-U And I see the same issue with the yuv422 images there as well. I'm guessing Apple's AVIF implementation must be incomplete?

Created by Alliance for Open Media and worked on by Netflix, Microsoft, and Google developers, AVIF is open source - you can even weigh in on image processing and spec issues.

I've been trying to find a way edit 14bit RAW files (.ARW) to an HDR capable format (HEIF/AVIF). In the process I found out there's an official AVIF encoder (1) by AOM that seems like it should be capable of creating HDR PQ stills.

Others samples are available here : https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Netflix/avif

AVIF can do something that resembles hierarchical JPEG and that could be useful for progressive decoding: you can have multiple layers/scales, where e.g. first a 1:4 image is encoded, then residuals to get to 1:2, then residuals to get to 1:1. Examples of this were recently added to the AVIF spec: https://github.com/AOMediaCodec/av1-avif/pull/134

we need Native Support for Python (or at least a reliable package) for managing the JXL files and up to this point brunsli (JXL_Patch) (which I couldn't make heads or tails of it) and jxlpy (which had problems installing on Python 3.11) were the only solutions I could find that came close to solving this issue, so ... what should we do?

To add to this, it's already possible to give this a try via building Brunsli from source:

https://github.com/google/brunsli

I personally use the cbrunsli/dbrunsli cmdline programs to archive old high-resolution JPEG photos that I've taken over the years. Having a gander at one subdirectory with 94 photos @ 354 MB in size, running cbrunsli on them brings the size down to 282 MB, which brings in savings of about 20%. And if I ever wanted to convert them back to JPEG, each file would be bit-identical to the originals.

Perhaps it's a little early to trust my data to JPEG XL/Brunsli, but I've ran tests comparing hundreds of MD5 checksums of JPEG files losslessly recreated by Brunsli, and have not yet ran into a single mismatch yet.

I can only say that I am very excited for the day that JPEG XL truly hits primetime.