3 comments
The layering reminds me a bit of opus 1.6 which similarly maintains backwards compatibility while laying in better audio for newer decoders, (and as a scalable decoding for those who don't want to use as much decode compute). <a href="https://opus-codec.org/demo/opus-1.6/" rel="nofollow">https://opus-codec.org/demo/opus-1.6/</a> <a href="https://news.ycombinator.com/item?id=46284313">https://news.ycombinator.com/item?id=46284313</a>
This is pretty cool. There’s a dearth of higher bit depth formats that are also compressed.<p>EXR and TIFF are really the only ones most people use but this opens up a fairly interesting option now for use cases where size is important.<p>Does this extend to the video codec? This would be pretty amazing for media reviews if so.
I'd argue JXL is fairly used, least in the photography circles I involve myself in. DNG 1.7 added JXL compression and at least for sharing raws around on the web it's been a boon.
Lightroom will output 16 bit ones but you can go up to 32 bit far as I'm aware.<p>Of course normal JXL files support similar as well, with meaningful progressive decoding at better ratios.
If you’re talking about embedded inside DNG, then you’re talking roughly a maximum of 14 bits. There’s not really much capture beyond that , whereas this + the other formats I listed provide 16 bits. That’s quite a significant jump
So when will support come to libavif, libaom, aom-tools and concerned packages? Are they pushed on to Arch already? Or still just upstream github for now?