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

Request: Re-open JPEG XL issue

bugs.chromium.org

Post reply on HN
Print view View original

121–130 of 164 posts

Re: Request: Re-open JPEG XL issue

#121

Post by cubefox »

networked wrote: post #111
cubefox wrote: post #76

Earlier quoted context omitted.

Here are visual comparisons between AVIF and JPEG XL on some test images with various bitrates / quality levels: https://afontenot.github.io/image-formats-comparison/#end-of... It seems AVIF has better compression at lower bit rates. At high bit rates they seem similar. AVIF especially shines for pictures with large homogeneous surfaces like the sky. However, AVIF is missing some important features, such as progressi…

A recent comment ( https://news.ycombinator.com/item?id=36286548 ) made me notice chroma contamination in low-BPP JPEG XL in this comparison. Since then, I have been leaning towards adopting AVIF for medium-low-quality pictures, especially of people. (People will be unhappy if their teeth are yellowed in post-production.) I am not so sure about AVIF and the sky. A reply to the comment I have linked shows an example w…

I also noticed more chroma contamination in JPEG XL, and overall more "ringing" artifacts.

Yeah, AVIF seems to remove noise fairly aggressively, or what it assumes to be noise. I think it looks pretty good in this sky example, although not overly faithful. It's less good when the removed "noise" is actual high frequency detail, e.g. on the fur of animals.

But what I meant with AVIF being good at homogeneous surfaces is that it apparently uses them sometimes to "save" bit rate, and to use it instead in other portions of the picture. Images with large surface portions tend to look significantly better in the rest of the image, e.g.

https://afontenot.github.io/image-formats-comparison/#clovis...

https://afontenot.github.io/image-formats-comparison/#us-ope...

I think here AVIF "small" looks overall better than JPEG XL "medium", e.g. in the details of the middle balloon basket, or the face of the tennis player.

I still think the lack of any progressive image loading makes AVIF completely unsuited for the web. The picture will only show once it was downloaded completely. That's a big step back from JPEG, and even more so from JPEG XL.

Re: Request: Re-open JPEG XL issue

#122

Post by worrycue »

altairprime wrote: post #113
brucethemoose2 wrote: post #87

Earlier quoted context omitted.

Its not just gamergate style rage though. Large and small companies have made statements in support of JPEG XL standardization.

> It's not just gamergate style rage though. Large and small companies have made statements in support of JPEG XL standardization. These facts support my point: the issue filed as linked above correctly cites one of those statements of support, without resorting to outrage, and has been successful at getting Chromium team's attention to the matter. https://bugs.chromium.org/p/chromium/issues/detail?id=145180... (Note…

What’s outrageous is Google’s BS reasoning for dropping the format.

They claim lack of interest when they (and Firefox) have been hiding JPEGXL support behind flags (and nightlies in the case of FireFox) yet WebP and AVIF is fully supported despite their similarly niche status.

Chrome’s support for JPEGXL was also already more or less complete when they decided to drop it.

Ironically though it has brought a lot of publicity to JPEGXL as “the format Google is trying to kill” in a Streisand effect sort of way. But with Chrome’s dominance that’s not enough to give it a fighting chance until Apple quietly announced support for it.

Re: Request: Re-open JPEG XL issue

#123

Post by neandrake »

trunnell wrote: post #112

Scanning the comments here and I don't see anyone addressing the elephant in the room: PATENTS. After a bit of searching, it's unclear what degree of "patent risk" comes with JPEG XL. JPEG historically was subject to patent troll lawsuits until the patent expired in 2006. Please note that it's not enough for there to be a "royalty-free reference implementation" of JPEG XL, even if it's licensed with Apache 2.0, becau…

Did google cite patents as one of the reasons they removed support initially? I thought it was all around lack of benefits and difficulty of maintenance.

Re: Request: Re-open JPEG XL issue

#124

Post by worrycue »

izacus wrote: post #82
untitaker_ wrote: post #15

this is a rando spamming the chromium issue tracker. what is newsworthy about this?

The fact that JXL is a new convenient crusade for people that hate on Chrome. You'll notice that noone is screaming at Mozilla for the same choice.

I am. It’s worse than Chrome in a way frankly in that JPEGXL is only supported in the Nightlies behind a flag.

However Mozilla has not completely dropped the feature like Google.

Re: Request: Re-open JPEG XL issue

#125

Post by rokweom »

meindnoch wrote: post #116
rokweom wrote: post #50

Earlier quoted context omitted.

With proper dithering, I would guess even rec. 2020 would be doable.

But that's cheating. You're effectively using N-times 8bit, by using N 8bit pixels to encode the intermediate values.

If we consider dithering cheating, then 10 bit without dither is also not enough for banding-free 4K, no matter the color space.

Re: Request: Re-open JPEG XL issue

#127

Post by lifthrasiir »

snickerbockers wrote: post #16

I'm just reading through the wikipedia page on this for the first time. Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis? If it's the former then I can see this offering a lot of utility over other image formats because you'd be able to disable the DCT on high-contrast macroblocks and finally be done with all those god-awful "check…

> Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis?

Tricky but it can be indeed done on a per-macroblock basis. The encoding itself is fixed per frame, but JPEG XL mandates zero-duration frames to be merged with the prior frame, so multiple frames with different encodings can be used for that. In fact I believe patches already work like this.

Re: Request: Re-open JPEG XL issue

#128

Post by mike_d »

PaulHoule wrote: post #9

As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…

> I want people to see something consistent with that on the web.

Don't get too hung up on picking a file format then. All sorts of middleboxes, CDNs, and edge network acceleration systems can potentially "right-size" your image for what the requesting device can handle optimally.

Re: Request: Re-open JPEG XL issue

#129

Post by aarmot »

ksec wrote: post #107
brucethemoose2 wrote: post #2

So, all it takes to consider a small community requested change in Chromium is a massive protest from thousands of users, small businesses, and Fortune 500 companies for almost a year... Or maybe they are just trying to keep feature parity with Safari.

I dont think anything has changed. JPEG XL being supported by Apple would only be 20% of user world wide. Assuming every one uses it. According to the initial Google thread this is likely not considered as high enough interest. With Google's study [1], by Google's Engineer, JPEG XL is no where near good enough compared to AVIF. None of the above facts have changed since Google Chrome's decision on JPEG XL. /S [1] htt…

That study is far from being conclusive. Please read also

https://cloudinary.com/blog/the-case-for-jpeg-xl

Re: Request: Re-open JPEG XL issue

#130

Post by undefinedland »

izacus wrote: post #82
untitaker_ wrote: post #15

this is a rando spamming the chromium issue tracker. what is newsworthy about this?

The fact that JXL is a new convenient crusade for people that hate on Chrome. You'll notice that noone is screaming at Mozilla for the same choice.

As a loyal firefox user since the 0.5 release which took 30s to start up, Mozilla is a non-entity these days. It exists solely so that Google can avoid legal disputes. In the mean time, a bunch of grifters have taken over Mozilla for their own financial purposes and push some activist causes rather than a solid browser.
Post reply on HN