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

111–120 of 164 posts

Re: Request: Re-open JPEG XL issue

#111

Post by networked »

cubefox wrote: post #76
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…

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 where AVIF smooths out a complex sky texture at every tested quality setting, but JPEG XL does not: https://afontenot.github.io/image-formats-comparison/#reykja....

AVIF is missing JPEG XL's ability to re-encode JPEGs losslessly and reversibly with a reduction in file size. It may prove a serious advantage for JPEG XL. AVIF also lacks anything like https://jpegxl.info/art/. :-)

Re: Request: Re-open JPEG XL issue

#112

Post by trunnell »

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, because you can't be sure from a glance that the Apache license patent grant includes all relevant patents. If you care about open source and free formats, you should look for two things: a comprehensive patent pool transferred to the standards body AND a royalty-free patent license to anyone with no strings attached.

The game here is that companies with potential claims over some techniques used within codecs have an incentive to withhold their patents from the official pool until years after adoption. Then they sue the biggest users of the codec (like Google) for obscene sums of money. That's why ALL of the patents used in a codec must be assigned to the standards body for open licensing, and you have to be SURE that none are withheld. This is difficult.

AVIF (and it's standards body, the AOM) was created in part (I believe) to solve this very problem. All the major tech companies are members and they've effectively agreed to a patent truce with regards to codecs.

This is arguably the most important commercial concern in distributing a browser for free that includes codecs. If you ship unlicensed codecs, some random company can crawl out of the woodwork 5 year later and sue you for a billion dollars.

In my view, AVIF only needs to be competitive with compression and quality. It patent risk is so low that it is the obvious choice. AVIF is truly open, there are multiple implementations, and its reason for existing is to solve the codec patent problem.

Source: I was near the activities within Netflix that helped found the AOM.

Disclaimer: I'm not a lawyer and this isn't legal advice; also I'm several years out of date w.r.t. JPEG XL specifically, so I'd be happy to be corrected about the relevant patent risk. Maybe someone has better info?

Re: Request: Re-open JPEG XL issue

#113

Post by altairprime »

brucethemoose2 wrote: post #87
altairprime wrote: post #51

Earlier quoted context omitted.

[flagged]

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 that I wasn't able to identify any viewpoints or opinions in your reply, other than the facts discussed above. If that's an oversight, I'm happy to revisit.)

Re: Request: Re-open JPEG XL issue

#115

Post by ComodoHacker »

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…

>a 4000x6000 image w/ my Sony looks almost like pixel art

Can you share some examples of such images/fragments?

Re: Request: Re-open JPEG XL issue

#116

Post by meindnoch »

rokweom wrote: post #50
meindnoch wrote: post #29

Earlier quoted context omitted.

Is 8bit enough to cover Display P3 without banding artifacts?

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.

Re: Request: Re-open JPEG XL issue

#117

Post by adrian_b »

wyager wrote: post #106
PaulHoule wrote: post #72

Earlier quoted context omitted.

The video is supposed to be encoded in Rec 2020. The panel is what it is. TV manufacturers negotiated to get a green primary close to what they could manufacture but really the panel is likely to be a little different and be color managed. My main monitor is a Dell that is very close to Adobe RGB which is great for print work because it covers the CYMK gamut well. I am interested in getting something better but it is…

> The video is supposed to be encoded in Rec 2020. The panel is what it is. Worth noting that it is physically impossible for current flat panel displays to have full coverage of rec.2020, because the spectral width of each primary is too wide with current flat display tech (LED, LCD, etc.) Full rec.2020 coverage requires the use of lasers, so you can get a ~spectrally pure primary. My prediction is that the next big…

The panels with quantum dots can theoretically reach an about 97% coverage of the Rec. 2020 color space, which should be enough for most purposes.

There are many commercial models which exceed a 90% coverage of the Rec. 2020 color space. However they are expensive, so they are used mostly in high-end TV-sets and only seldom in expensive computer monitors.

Re: Request: Re-open JPEG XL issue

#118

Post by FireInsight »

izacus wrote: post #109
FireInsight wrote: post #100

Earlier quoted context omitted.

I'm not aware, but the gist is that it's in some circumstances better than AVIF in size and/or quality. Both of the new formats are wayy better than good old JPEG and PNG, but AVIF is the one Google is pushing.

> but AVIF is the one Google ... but AVIF is the one Google, Apple, Edge, Firefox are pushing... Let's not be misleading here :)

Sure, everyone else is pushing AVIF too. And I don't mind, it's a great format.

Re: Request: Re-open JPEG XL issue

#119

Post by MaxBarraclough »

coldpie wrote: post #40
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.

Adding new image format support to a web browser is not a small change.

It's not a 5 minute job, sure, but compared to something like WebGPU it's tiny.

Re: Request: Re-open JPEG XL issue

#120

Post by acdha »

asddubs wrote: post #90
acdha wrote: post #79

Earlier quoted context omitted.

WebP was the classic Google “ship the prototype” move - they were hoping Chrome could muscle it through but it delivered only modest compression improvements (10-15% real world - the marketing papers promised 30% based on comparisons to unoptimized JPEGs) but it was missing features and had very primitive software support, making it harder to produce, deliver, or share (when Facebook switched, a common complaint was…

it's still a version of jpeg that supports transparency, and it's actually well supported (down to ios 14) to use without also having to deliver a fallback format now. it's not as good as it's successors, but if you are chosing one format and care about image size, it's the best choice.

I’m not saying it was terrible but that it took a long time for it to be worth the trouble unless you really needed transparency. It’s only been the last year or so that you could expect to be able to use it for anything non-trivial and not spend time dealing with tools which didn’t support it.
Post reply on HN