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

201–210 of 210 posts

Re: The case for JPEG XL

#201

Post by jonsneyers »

rocqua wrote: post #115
jokabrink wrote: post #52

I think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place. Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also…

Personally, the name always turned me off. I saw the option in photoshop when saving files, but my thinking went "jpg bad, jpg XL is a weird name, must be a minor incremental improvement over jpg".

I don't particularly like the name either, but it already had a name before it existed — that's the way JPEG works, the ones who write the Call for Proposals give it a name, not the ones who actually bring the proposals and design the new codec.

Anyway, I think "jxl" will in practice be the more common way to refer to JPEG XL images, and the full name will at some point become a matter of etymology and trivia questions.

Re: The case for JPEG XL

#202

Post by jonsneyers »

nigeltao wrote: post #183
jonsneyers wrote: post #111

Earlier quoted context omitted.

Did you compile fjxl with or without SIMD? That makes a big difference. And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice. The problem with PNG extensions for multi-threading is that it only works if you control th…

> Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded…

I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads.

Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns.

I agree that MT PNG does have a gentler transition path than introducing a new format. The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, which can be hard given how many existing deployments of png there are. Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc.

Also one disadvantage of MT PNG compared to JXL is that it splits the image in stripes, not tiles. For full-image decode, that doesn't matter much, but for region-of-interest (cropped) decode, tiles are a bit more efficient (no need to unnecessarily decode the areas to the left and right of the region of interest).

Re: The case for JPEG XL

#203

Post by jonsneyers »

pornel wrote: post #198
JyrkiAlakuijala wrote: post #194

Earlier quoted context omitted.

JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.

The major cost is on the AV1 side, which is there for video and which JPEG XL can't replace. The extra cost of recycling existing MP4+AV1 code to handle AVIF is minimal, smaller than JPEG XL can be.

Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding jxl quite a bit — libjpeg-turbo has quite some code and API functions that browsers don't actually need at all, and all it really needs to do is already there in libjxl.

So a variant of the "two for one" argument that justifies AVIF can also be used to justify JXL, since JPEG is needed anyway, even more so than AV1.

Also I am not so sure if the delta between AV1-only and AVIF is _that_ small, after all you do need to take care of alpha, color management, HDR, animation, and I suppose quite different code paths to get the decoded pixels in the right place than what is already there for the video case. Plus it looks like new things are still getting added to avif, like YCoCg-R and progressive previews, so it feels like it's a bit of a "moving target" spec like webp was in the early days. I see quite a few opportunities for bugs, different levels of support between different browser (versions), etc, that are not caused by AV1 itself but just by AVIF.

Re: The case for JPEG XL

#204

Post by jonsneyers »

pornel wrote: post #172
JyrkiAlakuijala wrote: post #154

Earlier quoted context omitted.

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.

That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off. It sucks that the codec with the best quality/filesize ratio doesn't just win.…

JXL currently has two levels:

Level 5 (intended for browsers), allows no CMYK, limits the number of channels to 7, limits the maximum lossless bitdepth to 14-bit or so (the actual criterion is that the intermediate buffers can be implemented using int16_t, so the actual bitdepth limit depends on what bitdepth-widening or -narrowing transformations the encoder used), and has some more limits like that.

Level 10 allows nearly anything the bitstream syntax allows, with a few "sanity check" type limits.

All of the coding tools and format features in the jxl spec do have useful potential applications for the Web, except for CMYK and very high precision lossless (and this is why a decoder conforming only to level 5 does not need to handle those). E.g. layers can be useful just for compression too (e.g. a text overlay on a photo background will likely compress better / with less artifacts if it is kept in layers).

The nice thing about jxl is that everything needed to display an image is specced in the codestream and handled by libjxl itself, so no need for a browser (or any other application) to implement these things themselves — and possibly not implement some of them, or not quite correctly. In avif (like in heic), a lot of codestream gaps have to be filled at the file format level (e.g. alpha), and that inevitably leads to bugs and differences between the different browsers/viewers.

Re: The case for JPEG XL

#205

Post by vazdum »

nigeltao wrote: post #183
jonsneyers wrote: post #111

Earlier quoted context omitted.

Did you compile fjxl with or without SIMD? That makes a big difference. And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice. The problem with PNG extensions for multi-threading is that it only works if you control th…

> Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded…

And it is better to use Clang, with other compilers libjxl performance can decrease significantly for some reason

Also fjxl has an effort option, with 0 or 1 it will be even faster, but with less compression

Same for libjxl, there are faster efforts 1 and 2, and effort 3 as far as I know works well for photos but not so much for the rest

Re: The case for JPEG XL

#206

Post by pizza »

JyrkiAlakuijala wrote: post #190
pizza wrote: post #176

Earlier quoted context omitted.

Hi Jyrki, this is all very interesting. A couple questions for you, while you’re in this thread: - where is the best documentation for the Butteraugli metric? I’ve found it quite difficult to find a high-level rationale/design notes for the metric. - I also understand that JXL doesn’t try to explicitly optimize against Butteraugli distance unless you invoke the higher effort levels, and then, it uses a slightly diffe…

1) Butteraugli Butteraugli is largerly a 'learned' metric, just very small with its ~200 parameters. I implemented possible components and tuned them and their interactions using methods similar to machine learning. Describing it to humans should be possible, but going all the way is going to be the same as describing DNNs. SSIMULACRA 2 is taking the same approach and getting far better results than a previous effort…

Awesome, thank you!

Re: The case for JPEG XL

#207

Post by sureglymop »

JyrkiAlakuijala wrote: post #191
sureglymop wrote: post #186

Earlier quoted context omitted.

As a swiss person, all these names of common christmas cookies here are making me hungry.

others are real Swiss cookies, but butteraugli is a made up Pseudo-Swiss word based on voisilmäpulla, a Finnish sweet bread

Interesting... Butteräugli does sound like a swiss cookie though. I can even imagine what it looks like based on the name.

Re: The case for JPEG XL

#208

Post by rockdoe »

JyrkiAlakuijala wrote: post #135
Heikete wrote: post #53

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting f…

For me, the competition there is pretty simple. The browser shouldn't crash. Until now I used firefox on my home ubuntu box (intel nuc). Yesterday it started crashing, and crashed about 15 times. I downloaded chromium and it didn't yet crash. Now, I'll probably move to it for home computer browsing, too. Even when I don't agree with their decision on not enabling JPEG XL by default. If there is a browser that has it…

>intel nuc

Gemini Lake chip?

https://www.mozilla.org/en-US/firefox/106.0.5/releasenotes/

Re: The case for JPEG XL

#209

Post by nigeltao »

jonsneyers wrote: post #202
nigeltao wrote: post #183

Earlier quoted context omitted.

> Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded…

I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads. Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns. I agree that MT PNG does hav…

> I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so,

In case it wasn't clear, the 0.630 fjxl encode speed number in the top level README.md in that commit is after normalization such that QOIR is 1.000. After all, absolute numbers are hardware dependent.

If you look at the doc/full_benchmarks.txt change in the same commit I linked to, fjxl encode speed clocks at 106.48 megapixels per second. It's just that QOIR encode speed clocks at 168.90 megapixels per second (and fpnge at 312.59).

Re: The case for JPEG XL

#210

Post by nigeltao »

jonsneyers wrote: post #202
nigeltao wrote: post #183

Earlier quoted context omitted.

> Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded…

I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads. Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns. I agree that MT PNG does hav…

> The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage,

Well, for PNG, Apple have shipped exactly that. It was something they could unilaterally do without e.g. having to get all of the major browser makers on board.

Apple's PNG encoders (i.e iOS dev SDKs) produce multi-thread-friendly PNGs and their decoders (i.e. iOS devices) reap the benefits. And unlike trying to introduce a new but not-backwards-compatible-with-PNG format (JPEG-XL), other PNG decoders can still decode these images. They just don't get the speed benefit.

> Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc.

It's forwards compatible too. Apple's PNG decoder will use MT decode if the PNG image was encoded with MT metadata, but Apple's PNG decoder can still decode arbitrary PNG (using its pre-existing single-thread code path).

Post reply on HN