Live data from Hacker News

Request: Re-open JPEG XL issue

bugs.chromium.org

101–110 of 164 posts

Re: Request: Re-open JPEG XL issue

#101

Personally, I've got no great love for these new image formats. It's always a pain in the ass when you discover your phone has actually been saving your photos as heic or webp or avif or whatever and hardly anything will open them. I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 3…

Even if you don't care at all about file sizes (which is definitely A Take), there is the whole other side of improving image quality.

Everything about computer imagery is pretty sadly limited when compared to the capabilities of human eyes and brains. And for quite some time now the ends of the pipeline (camera sensors and computer displays) have been improving, but are bottlenecked by the middle of the pipeline (image formats).

Re: Request: Re-open JPEG XL issue

#102

Can someone summarize the issue with JPEG XL? Is this something that really matters? I've seen this mentioned a couple of times in the last few days but I don't see what the big deal is, is it really that necessary?

JPEG is 30 years old so we need something more modern (better compression, less visual artifacts, web optimized, etc...). There already was a plan to change it with JPEG 2000, but it failed, obviously, as we still use jpegs. Now several formats are competing, most notably AVIF (which is basically just single AV1 video compressed frame) and JPEG XL. JPEG XL might be slightly better in some cases (as AVIF is based on a…

Thank you! A lot of the context was lost for me!

Re: Request: Re-open JPEG XL issue

#103

Earlier quoted context omitted.

> 4K TV’s use Rec 2020 Is defined by some standard to be able to be declared "4K", or is it just what seems to be happening because all/most of the panel makers just threw it in?

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 only difference between Adobe RGB and the PAL/SECAM color TV-sets from 1970 is in the primary green color, which is much more pure in Adobe RGB and it indeed makes Adobe RGB great for print work.

On the other hand, for viewing images on monitors, Adobe RGB is not a desirable color space. The worst primary color of PAL/SECAM and of the closely related SMPTE C and Rec. 709 color spaces is the primary red color.

While in the blue and green regions the colors that are not representable in PAL/SECAM/SMPTE C/Rec. 709 can be represented by reducing their saturation, in the red corner, from purple to yellow, besides colors that can be represented by reducing their saturation there are also colors that can be represented only by reducing both their saturation and their brightness.

Moreover, in the red corner, from yellow to purple, there are many frequently encountered objects with such saturated and bright colors, e.g. flowers, fruits and clothes.

So the really noticeable improvement in color reproduction on monitors is when passing from PAL/SECAM/SMPTE C/Rec. 709/Adobe RGB to monitors with DCI-P3 primary colors.

DCI-P3 keeps the primary blue of PAL/SECAM, but it has much better primary red and primary green colors. The green is not as good as that of Adobe RGB, but the better red provides a much more visible improvement.

Many relatively cheap monitors, e.g. all my Dell monitors, have a menu option to replace the default sRGB color space with the "DCI-P3" color space (and they can display almost 100% of the DCI-P3 color gamut). On any such monitors, by "DCI-P3" is meant the Apple Display P3 color space, i.e. DCI-P3 primary colors combined with the PAL/SECAM D65 white and with the sRGB non-linear transfer function.

In cheap monitors, the DCI-P3 color gamut with 10 bit per color component is the best that can be found. The monitors whose color gamut is a larger fraction of the Rec. 2020 color space are expensive, because they normally must use quantum dots or OLED or both.

Nevertheless, as the output color space for any high-quality photograph, the Rec. 2020 color space is preferable, even if most people who would look at the photograph now would clip its color gamut to the sRGB or DCI-P3 of their monitors. However those who have better monitors, whose numbers will be increasing in the future, will be able to see any color that can be displayed by their monitors, without having the quality of the photograph already degraded by whoever has processed it.

Re: Request: Re-open JPEG XL issue

#104
post #25

Earlier quoted context omitted.

Because lots of people are hoping Google will change is mind and this is a small concrete step towards that.

Is there a good writeup about why people want this over other, existing formats?

> Is there a good writeup about why people want this over other, existing formats?

All the existing JPEG files can be converted to JPEG XL while gaining 20% size and still having all the exact same data. There are, what, tens or hundreds of billions of JPEG files out there for which the "original" (RAW or anything) is long gone (or never existed) and people don't want a "photocopy of a photocopy".

You can even decompress the JPEG XL back to the original JPEG file, bit for bit.

For that alone there shouldn't be any question: it's a wonderful feature.

In addition to that Apple / Safari are going to support JPEG XL and there are huge number of applications supporting that format.

People don't want this "over" existing formats. They want this in addition to other formats.

And I think they'll get it.

Re: Request: Re-open JPEG XL issue

#105

Earlier quoted context omitted.

> And my experience is that AVIF falls down at that, it does not really save bits compared to JPEG and WEBP at high quality. In all the comparisons I've seen, it's not even a contest. "I picked this image because it's a photo with a mixture of low frequency detail (the road) and high frequency detail (parts of the car livery). Also, there are some pretty sharp changes of colour between the red and blue. And I like F1…

It's a Jedi mind trick. The compression artifacts in the self-shadows of the red bit of the car to the left of the driver's head look awful to me. It's true that the compression artifact blends in pretty well and you might think the car really looks like that but personally I can't unsee things like that once I look at them in comparison. The thing is that it is that play of reflections and shadows that makes an expe…

> It's a Jedi mind trick.

All compression is. :^) The additional twist is that our eyes/brains do a great job at glossing over compression artifacts that we're used to.

When you expand the image, you can change the formats on both sides for A/B testing. Comparing "JPEG - 20.7 kB" to "AVIF - 18.2 kB" is an enlightening like-vs-like size comparison.

I'd be happy to do an AVIF encode of a large uncompressed/losslessly compressed image that meets your "near visually lossless" bar. I'm assuming that JPEG must do better in comparison to AVIF at large file sizes, but I can't find good examples of this.

Re: Request: Re-open JPEG XL issue

#106

Earlier quoted context omitted.

> 4K TV’s use Rec 2020 Is defined by some standard to be able to be declared "4K", or is it just what seems to be happening because all/most of the panel makers just threw it in?

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 move in display tech after 8K will be a transition from LCD/LED to VCSELs or some other teeny laser pixel, so they can advertise full rec.2020 coverage.

After that, maybe tunable quantum dot lasers so they can get full CIE 1931 coverage, but that's probably at least 15-20 years away.

Re: Request: Re-open JPEG XL issue

#107

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] https://storage.googleapis.com/avif-comparison/index.html

Re: Request: Re-open JPEG XL issue

#108
post #98
post #96

Earlier quoted context omitted.

it is implemented, it's just not released. if there's no plans, why did they add the feature flag to begin with?

Same reason Chrome did. Chrome team themselves quoted no interest of those browsers as the reason for removal of the flagged code. Seems like an obvious way to pressure Google into supporing JXL would be to get Mozilla to launch their support, together with Edge and Safari?

but you do understand the difference between getting mad about a hypothetical situation vs something that actually happened, right?

Re: Request: Re-open JPEG XL issue

#109

Earlier quoted context omitted.

Is there a good writeup about why people want this over other, existing formats?

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

Re: Request: Re-open JPEG XL issue

#110

Personally, I've got no great love for these new image formats. It's always a pain in the ass when you discover your phone has actually been saving your photos as heic or webp or avif or whatever and hardly anything will open them. I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 3…

WebP was I believe the first image format that supported lossy compression with transparency. You could argue that you can just use PNG if you want transparency, but allowing lossy compression if you need alpha is more like 10x smaller, not a mere 60%. Also it came out back in the era when 4MB for a web page was a lot.

AVIF was the first format accepted by the web that supports HDR (not already tone-mapped HDR, true HDR.) Which maybe you don't personally care about, but is something that fundamentally cannot be done with existing JPEG and PNG implementations.

AVIF might not have happened, and the above paragraph might have read "HEIC", if HEVC had had similar licensing terms as H.264. But there's no predicting that stuff before it happens.

Post reply on HN