Live data from Hacker News

The case for JPEG XL

cloudinary.com

81–90 of 210 posts

Re: The case for JPEG XL

#81
post #45

Earlier quoted context omitted.

Google don't need to resort to such tricks when they can just bludgeon everyone to death. Se how they forced support of VP9 and AV1: https://www.protocol.com/youtube-tv-roku-issues

Not to mention WebP, which I guess is the elephant in the room when they say that JPEG XL "does not bring sufficient incremental benefits over existing formats".

I don't personally know if that's true for JPEG XL, but WebP was kind of underwhelming.

I remember all the same conversations happening now on HN, but for WebP back in the day, and Mozilla being really doubtful it was worth the maintenance effort. FF eventually added it... in 2019, and Safari in 2020. Only two years later we're discussing a format that will completely supplant it, but the browsers will have to maintain WebP forever.

Re: The case for JPEG XL

#82

Earlier quoted context omitted.

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.

Also libwebp reached 1.0 only about 8 years after it was added to Chrome. So I don't think this is a major criterion. That said, we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, preferably first half.

And Mozilla waited for libwebp to reach 1.0 before making the plunge to support it in Firefox. One of the main issues was that libwebp was willing and frequently made backwards-incompatible changes to the codec in the 0.x days; Google simply didn't care about breaking images, but Mozilla cared.

Re: The case for JPEG XL

#83
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…

I started using Firefox as my daily browser when the Firefox Photon redesign launched and reluctantly switched to Brave when they removed it. RIP to the best looking default browser skin of all time.

Re: The case for JPEG XL

#84
post #31

Earlier quoted context omitted.

Mozilla is one of the founding members of AoM backing AVIF/AV1. They're shipping AVIF support enlabled. The JPEG-XL bug hasn't received any news or updates for at least a year now and the support is disabled on all stable builds (meaning: you can't even enable it with a flag since it's not compiled in). You can enable a flag on nightlies.

It hasn't received news or updates because it has been locked. Basically Mozilla's position seems to be that they're not going to do anything on this front until Chrome does it first. I can only assume the decision makers at Mozilla feel the need to "prove their loyalty to the AOM", just like the Chrome codec devs, by blocking non-AOM codecs, in particular JXL.

Or, they just don't have the resources, market share, or interest to fight this battle. I can think of many better things FF should do other than try to push forward a new image format.

Re: The case for JPEG XL

#85
post #6

Earlier quoted context omitted.

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).

AVIF practically comes along "for free" by just having AV1 support in the first place.

Re: The case for JPEG XL

#86
post #78

> A unique feature of JPEG XL is that it is possible to recompress existing JPEG images (of which there are a lot out there!) to a JPEG XL file that is on average about 20% smaller, without introducing any loss. In fact, the bit-exact same JPEG file can be reconstructed from the JPEG XL file. I wasn't aware of this and this is actually crazy, and freaking brilliant from a migration point of view. I wonder how that wa…

The journey to JPEG XL started with guetzli (which started with butteraugli to guide loss in JPEG encoding) and brunsli. Guetzli is a great (but very very slow) JPEG encoder. Brunsli is a classic JPEG1 recompressor. We mixed those and got the first version of PIK. We added some forced format-level progression, adaptive quantization, filtering, larger DCTs, integerated HUIF as lossless/super-progressive coder, and adopted some WebP lossless features into HUIF (Select, 2d-LZ77, entropy clustering).

The final version still had brunsli-like features and we surfaced those as a JPEG recompression system.

Re: The case for JPEG XL

#87
post #68

Earlier quoted context omitted.

Preface: It's difficult to write about stuff like this and I know reading it back to myself after will leave me wanting to redraft it 5 times over but it's 1am already. But, if this post is wrong/incorrect or is missing other factors that are too important to leave out then please let me know and I'll amend or even delete it. My focus is on the technical side of things. So anyway: > why it itsn't the case for other i…

There’s a Twitter thread by a JPEG XL dev who tries to explain some of this in terms of the XYB color space giving more bits to dark tones: https://mobile.twitter.com/jonsneyers/status/155021585930558... But I’m not clear if this was a design goal of JPEG XL, or a theoretical side-benefit, or something you would need an HDR screen to appreciate (I couldn’t tell the difference in any of the example images, but those m…

In this case I would say that regardless of intent (which may still be important) we should go for the better image format if we have the option. Like, to take the historical example mentioned in the NYT article linked above, this is obviously bad:

> Concordia University professor Lorna Roth’s research has shown that it took complaints from corporate furniture and chocolate manufacturers in the 1960s and 1970s for Kodak to start to fix color photography’s bias.

.. but without excusing any of that, black people were still better off with the newer films.

Similarly, regardless of the intent of the JXL design, if it is the more "inclusive" tech then that speaks in favor of it.

Also, the difference in the example images requires you to look actively look for JPG artifacts. That's something that usually only codec developers and people who work with images for their day job do. Almost everyone else subconsciously does the opposite: they learn how to "look past" the compression artifacts. But speaking as someone who did spend a lot of time trying to optimize JPG sizes for a short while in his life there is definitely a difference.

The difference is hard to see when compressing an image once, but keep in mind that we live in a world where images go through lossy recompression dozens of times, causing the "needs more JPEG" meme[0][1] to live on even when it should be a thing of the past. If your image is, say, 5% more visually lossy for black people that adds up.

[0] https://knowyourmeme.com/memes/needs-more-jpeg

[1] http://needsmorejpeg.com/

Re: The case for JPEG XL

#88
post #68

Earlier quoted context omitted.

Preface: It's difficult to write about stuff like this and I know reading it back to myself after will leave me wanting to redraft it 5 times over but it's 1am already. But, if this post is wrong/incorrect or is missing other factors that are too important to leave out then please let me know and I'll amend or even delete it. My focus is on the technical side of things. So anyway: > why it itsn't the case for other i…

There’s a Twitter thread by a JPEG XL dev who tries to explain some of this in terms of the XYB color space giving more bits to dark tones: https://mobile.twitter.com/jonsneyers/status/155021585930558... But I’m not clear if this was a design goal of JPEG XL, or a theoretical side-benefit, or something you would need an HDR screen to appreciate (I couldn’t tell the difference in any of the example images, but those m…

Also not sure if this is a Twitter issue (wait, another reason not to use twitter? So why do people keep using it for something it’s bad at? /rant), but I got a different result.

I can clearly see the differences between the encodings (I shuffled the images and sorted them by perceived quality), and I disagree that JXL looks better / is less racist. For both sides, the AVIF version looks significantly better, but especially for the black woman. The white woman already has fewer visible details that can be lost, the black woman has more, and JXL just smoothes those over, making it look like someone used the smudge tool (in general, but it’s especially bad here [0]).

So going from this example, I’d say AVIF wins by quite some margin.

[0]: https://i.imgur.com/2WU6iKe.png

Re: The case for JPEG XL

#89

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 fr…

Could you elaborate on 5) thermal camera support? How thermal camera could replace normal camera (this only capture infrared light?)? Why thermal camera are more ecological-friendly?

Re: The case for JPEG XL

#90
post #39

Earlier quoted context omitted.

> people-of-color skin is better represented in JPEG XL wait what? What is this woodoo and why it itsn't the case for other image formats in which encodings color in RGB?

Why do you call this “woo” pejoratively right off the bat before admitting you don’t know?

I suppose using a term that colloquially means "black magic" might be a little (skin) tone deaf in this context, but I think it was intended as a positive thing. As in "what kind of magic is JPEG XL using to be better, and what is everyone else doing wrong?"

I admit the wording is kind of ambiguous though

Post reply on HN