Hacker News Reader

Comment by xeeeeeeeeeeenu | Hacker News Reader

That may hurt JPEG XL adoption, which is a shame, because it's a much better format.

Probably not. One of JPEG XL's features is the ability to losslessly transcode existing JPEG images to JPEG XL while also reducing the file size:

https://jpeg.org/jpegxl/

Reducing the size of existing image collections with zero quality loss will make JPEG XL a success no matter what else happens.

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.

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

Brunsli works very well, but is not compatible with the final JPEG XL format. For being able to reduce the binary size of libjxl we decided to use a more holistic approach where the VarDCT-machinery is used to encode jpegs losslessly. This saved about 20 % of the binary size and reduced attack surface. Now the decoder binary size is about 300 kB on Arm.

I'm really rooting for JPEG XL. AVIF is good but it's clearly a video codec adapted to fixed images, whereas JPEG XL covers a lot more use cases important when dealing with images (ie palette images, progressive decoding, more bit depths options, JPEG lossless recompression, etc). Adding to that producing large AVIF images takes an ungodly amount of memory and time right now.

Could you explain how/why?

"AVIF is currently better at low image quality. JPEG XL is currently better at medium and high image qualities, including the range of image quality used in the internet and the cameras today." https://encode.su/threads/3397-JPEG-XL-vs-AVIF#:~:text=AVIF%....

How do they compare from patent encumbrance perspective? AVIF is supposed to be protected by AOM for everyone to use.

The JPEG XL reference implementation is under the Apache 2 license, which means that it comes with a royalty-free patent grant. So pretty much the same as AVIF (BSD 2 clauses + royalty-free patent grant).

That sounds good, but AOM also provides a rather heavy weight protection against patent trolling and similar threats which is a benefit. It's similar to OIN in that sense.

Reference implementation is irrelevant to the patents which cover the use of underlying codec. The codec might get AOM protection, but then there's always some companies with patents outside of AOM.

H.265 debacle with 2 patent holder groups is a good example of that.

Those outside the AOM will face the combined power of AOM if they attack. In other cases it depends on who defends the codec.

H.265 is an anti-example, because there patents were pooled for offensive purposes to begin with, while AOM pooled resources for defense. I.e. something like MPEG-LA exists to extort money, not to defend anyone. That's also why you got two separate pools there. Patent aggressors don't want to share, each of them wants to get all the loot for themselves.

The creators of JPEG XL have all agreed to give royalty free patent licenses to any relevant patents they own, so I think it compares quite well.

AVIF is a format that puts an AV1 bitstream into a HEIF container. You're thinking about what AOM said about AV1 [6], not AVIF; they should not (and in fact do not) make that claim for AVIF -- which builds on HEIF that isn't their work -- though you ought to judge the situation for yourself [7].

I am not a lawyer, and I realize there's a fine line between genuine concern and spreading FUD, but in the spring of 2019 I looked into the patent situation around the HEIF container itself [1] -- the container upon which AVIF builds -- and skimmed through the 5 US patents I found, which cover some techniques that can be used in the format. Most of them can probably be avoided for the purposes of an AVIF file, but patent US20160232939A1 [2] in my reading seems to be about in-container signalling to express relationships between a "static media item" and "one or more entities" that together "form a group", and "indicating, in the file, a grouping type for the group". The patent appears to be written in a way to allow this definition to encompass, say, a thumbnail and a bunch of frames thereafter, or, say a master image and a set of pictures derived from it, or alternate camera angles of the same thing. Some of these techniques sound like stuff we've seen before, but as is common in patents, the precise wording of claims is often key, and this is where patent lawyers come in.

A thorough look of the AVIF specification [3] and the patents registered with the MPEG LA about this format [1] is likely wise before any widespread deployment that makes use of advanced features of the HEIF container; using it to hold exactly 1 'one-layer' still-image is probably fine.

Additionally, in my reading [5], the HEIF reference software released by Nokia [4] includes a patent grant for non-commercial evaluation, testing and academic research only.

[1] https://news.ycombinator.com/item?id=19874321 [2] https://patents.google.com/patent/US20160232939A1/ [3] https://aomediacodec.github.io/av1-avif/ [4] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT [5] https://news.ycombinator.com/item?id=19874368 [6] https://en.wikipedia.org/w/index.php?title=AV1&oldid=9976507... [7] https://github.com/AOMediaCodec/av1-avif/issues/2

I had that question before too, still not sure why they picked HEIF for AVIF, instead of using some more obviously free container. They could easily avoid all the above.

I just wanted to mention XL is currently not optimised for low bitrate. So there are lots of potential to improve.

And I do think taking median Image size and bitrate on Internet was the wrong point of optimisation. Lots of image on the internet just aren't properly optimised.

I think and I may be wrong, the format is now finalised. ( The original schedule was last July... so it was delayed abit ) People who are interested could start testing it.

JPEG XL's great properties extend to about 3-5x lower bitrates than what are used in the Internet and to about 10x lower bitrates than what are used in cameras. Also some improvement is happening in that area.

Here's a great article on the topic from one of the JPEG XL creators: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...

Reply on news.ycombinator.com