Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case for JPEG XL

cloudinary.com

Post reply on HN
Print view View original

21–30 of 210 posts

Re: The case for JPEG XL

#21

Post by lifthrasiir »

gardaani wrote: post #15

I hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding. Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

> They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

This is a common misconception; JPEG XL is jointly created by Cloudinary (which employs the author of FLIP/FUIF) and Google Research Zurich (which previously created PIK, and employs authors of Brotli and WebP lossless format as well) with an official blessing by JPEG (which mostly set the goal for the format). The only difference here is that the authors do not belong to the Chrome team.

Re: The case for JPEG XL

#22

Post by Tomte »

sedatk wrote: post #3

Browser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all

I'd have expected HEIF to be implemented in Safari, at the very least mobile Safari. Did Apple really not include their native image format on recent iPhones?

Re: The case for JPEG XL

#23

Post by lifthrasiir »

hypothesis wrote: post #19

On one hand numbers do not mean much, but I think that releasing a 1.0 version of official library would at least help with morale and signal some completeness. I’m sure there are reasons making fresh 0.x releases even after creating a standard format, but it was a bit disappointing after years of waiting, even before this blow by certain browser maker.

libavif is still not at 1.0 (in fact, 0.11.1 at the time of this writing). Having a 1.0 release is good, but not relevant to this matter.

Re: The case for JPEG XL

#24

Post by izacus »

gardaani wrote: post #15

I hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding. Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

Safari has already shipped AVIF support with iOS 16 and macOS Ventura.

Apple is a member of AoM backing AV1/AVIF formats, together with other browser vendors.

Re: The case for JPEG XL

#25

Post by JyrkiAlakuijala »

Beautifully written article -- I couldn't agree more. From my personal point of view the biggest impact are:

1) e-commerce textures such as cloths are more faitfully represented -- more trust in e-commerce, more revenue

2) more equity for selfies, people-of-color skin is better represented in JPEG XL, selfies in general look more people like with less smoothing of skin performed at compression stage -- I'm a great friend of the idea that filtering should not be built into the compression so that all kinds of images can be transmitted

3) more compression, faster and cheaper to load

4) better progression -- unlike I believe AVIF does, JPEG XL progression does not impose more decoding cost for sequential, progression does not make compression density worse

5) thermal camera support -- I believe thermal cameras have huge ecological and cost optimization opportunities and more phones should have thermal cameras in them to facilitate the shift away from fossil fuels

6) small images -- thumbnails and sprites etc. do not necessarily need spriting with JPEG XL. That is a nice increase in system level simplicity. JPEG XL overhead is about 10-20 bytes whereas AVIF overhead seems to be 600 bytes or so.

7) 'it just works, no surprises' -- the worst case image quality degradation in any quality setting are much less severe and much less common than in other formats

Re: The case for JPEG XL

#26

Post by peppermint_gum »

eslaught wrote: post #6
sedatk wrote: post #3

Browser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all

I was a little surprised about AVIF, so I looked it up and it doesn't seem to be quite there yet (though it's getting there). macOS Safari requires Ventura, and no support yet on Edge. https://caniuse.com/avif

The funny thing about AVIF support in Chrome is that, unlike JPEG XL, there was no experimental period. It was enabled by default from the beginning (in Chrome 85).

Re: The case for JPEG XL

#28

Post by todotask »

gardaani wrote: post #15

I hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding. Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

Google Brunsli was adopted for JPEG XL.

https://github.com/google/brunsli

https://www.codercto.com/a/103418.html

Re: The case for JPEG XL

#29

Post by JyrkiAlakuijala »

hypothesis wrote: post #14
Nathanba wrote: post #7

As simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Pers…

This is a valid argument, but which of the contenders are using Rust or similar security minded languages? WebP appears to be written in C++, perhaps because underlying video codec is also written in C++…

We wrote WebP in C -- in the creative phase of codec and format development I kept it in C++, the feasibility proto was initially launched in C++ (perhaps 0.2 version of the lossless coding, late 2011), but I ported it to C a few months after that and handed it over to the WebP production team (early 2012) who kept making improvements like streaming decoding

Re: The case for JPEG XL

#30

Post by lifthrasiir »

hypothesis wrote: post #14
Nathanba wrote: post #7

As simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Pers…

This is a valid argument, but which of the contenders are using Rust or similar security minded languages? WebP appears to be written in C++, perhaps because underlying video codec is also written in C++…

There is a Rust WebP decoder in image-rs [1], presumably independently written from the specification.

[1] https://github.com/image-rs/image/tree/master/src/codecs/web...

Post reply on HN