[PaulHoule]

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 use Rec 2020 which has a huge color gamut, because it is covering a bigger space, 8-bit color is not enough, you need to go to 10-bit, 12-bit or more (I process in 16 bits) and neither JPEG or WEBP can handle that. AVIF can, but so can JPEG XL.

I know people doing synthetic tests (instead of looking at the image they run a program that estimates how bad compression artifacts are) are impressed with AVIF but I’ve done some shootouts with JPEG/WEBP/AVIF/JPEG XL where I look at images with my own eyes.

For pictures that are moderate-low quality (say images for a blog) I think AVIF does very well, but I want to publish pictures I took with my mirrorless where I work really hard to get them “tack sharp” (e.g. sometimes a 4000x6000 image w/ my Sony looks almost like pixel art when you blow it up) and I want people to see something consistent with that on the web. And my experience is that AVIF falls down at that, it does not really save bits compared to JPEG and WEBP at high quality. JPEG XL gives superior compression at high quality and it supports high color depths and it’s an option I’d really like to have.

[CharlesW]

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

Roughly speaking, at an acceptable quality, the WebP is almost half the size of JPEG, and AVIF is under half the size of WebP. I find it incredible that AVIF can do a good job of the image in just 18 kB."

https://jakearchibald.com/2020/avif-has-landed/

It'd be interesting to see file size comparisons of AVIF lossless images vs. JPEG's "almost lossless" 100% compression, but I haven't run across any yet.

[majormajor]

That seems like a bad image for the stuff the OP is talking about - large print high detail stuff - since it's so small, but the AVIF "acceptable" still, even at low res, seems to be clearly throwing away detail compared to the JPEG "acceptable". Look at how the JPEG preserves some of the body seam in the second "l" in RedBull, for instance. So ok, it's a quarter the size, but they aren't showing me how big an AVIF with the same detail as the JPEG would be.

They're just showing that it can do a less-offensive job of erasing detail smoothly to take filesizes down to tiny levels than WebP or JPEG? But "tiniest size with least offense" is VERY different than "best size with greatest detail."

[PaulHoule]

Exactly, that's what I'm talking about.

For some applications people would be really happy with that F1 car image and I would even be happy with it for some applications (e.g. some random image to give spice to a blog) but for my photograph I'd say that's pretty lossy.

[PaulHoule]

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 expensive sports car look so sexy.

[CharlesW]

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

[account42]

> Comparing "JPEG - 20.7 kB" to "AVIF - 18.2 kB" is an enlightening like-vs-like size comparison.

You can't extrapolate that comparison to higher bitrates though - so unless your use case doesn't require preserving image detail (i.e. the images might as well not be there), both formats are inadequate at that size.

[yakubin]

This "acceptable quality" photo at the top in AVIF made me initially think someone took a blurry photo. I only understood what happened after switching to original and JPEG, which look much better. So this is an apples-and-oranges comparison IMO. I'd never use that AVIF version on my photography website.

[JyrkiAlakuijala]

I don't enjoy seeing compression artefacts or blur or other loss of detail.

I don't want the internet to look like that F1 car to save a few milliseconds or $0.0000001 for the company sending the pic to me.

I certainly don't want my family photos to look like that.

I don't want the photographs on the internet to become much faster, much cheaper and much worse. I'd like them to become a bit faster, a bit cheaper, but also more crisp, vivid, emotionally engaging, and realistic.

[elishah]

Yes, the unfortunate thing is that Google is not interested in a higher quality Web so much as they are in a Web that is cheaper to index and serve.

So it's unsurprising that they have pushed the format optimized for "as few bits as we can get away with before things like too terrible" rather than actually improving quality and extending capabilities.

[cubefox]

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 progressive image loading. The maximum resolution is apparently also quite limited.

[networked]

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

[cubefox]

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.

[JyrkiAlakuijala]

The 'Large' is still relatively low quality -- you can observe this by 3x zooming and comparing to original.

You can easily see that AVIF blurs (beautifies faces) and removes properties of the red cloth in the 'end-of-show' image.

Internet average image quality is higher than the 'Large' setting, so those names are not representative of actual internet use. Camera and image processing use is even of much higher quality.

[cubefox]

No, I think Internet average quality is a lot lower than AVIF or JPEG XL at "large". Instead of using such a high bitrate to save a small amount quality, it makes much more sense to use a low bit rate with a significantly higher resolution, and end up with the same file size.

Even cameras often have relatively little detail per pixel, since they do interpolate a lot of information due to the usage of Bayer filters (which record only one primary color per pixel instead of full RGB values), and because anything with less than perfect lighting will be somewhat noisy and blurry anyway.

[JyrkiAlakuijala]

I made quite a bit of unpublished effort to understand the average quality. Web almanac media chapter is showing average jpeg bpp density. In my collection median quality as reported by image magic is 85 and roughly 2–2.5 BPP.

[account42]

Compare the AVIF with the original and you see how bad it is. You need to make the comparison at a bitrate where at least one of the format gives acceptable results.

[throw0101a]

> 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?

[PaulHoule]

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 not so clear to me that you can really get a Rec 2020 computer monitor other than a crazy expensive monitor from Dolby. Maybe I gotta download a bunch of monitor profiles so I can know what various monitors really support as I’ve already developed a system for simulating how channel separation works for red-cyan stereograms even on monitors I don’t have.

A better TV has been on the agenda too except somehow people keep giving me free TVs on the railing edge such as a Walmart TV which had great sound (better than many sound bars) that had the backlight burn out, then I got gifted a Samsung which sucks but is working fine in my TV nook downstairs. My main AV room doesn’t have room for anything bigger than what I’ve got unless I move everything which I don’t have a good plan for…

[wyager]

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

[adrian_b]

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.

[adrian_b]

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.

[innocenat]

ITU-R UHDTV Standard, the mainstream 4K TV standard, use Rec 2020.

In theory you can use any color primaries with any video resolution in computer (NOT on TV as those normally only support mainstream standard) as long as the the color space metadata is properly set, but in practise, some softwares ignore the metadata or the metadata got lost in the video processing chain. So in general, 4K video use Rec 2020, HD/FHD use Rec 709, and SD use Rec 601, for maximum compatibility.

[mike_d]

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

[ComodoHacker]

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

Can you share some examples of such images/fragments?

[gsich]

JPEG has 12-bit somewhere in the standard, not sure on where it's implemented.

[doodlesdev]

I'm not aware of any photo editing software that can export 12bit JPEG (although to be fair I don't know many), I am aware though that JPEG 2000 supports 12bit color and that JPEG XT supports up to 16bit color, perhaps that's whats causing the confusion?

[robinsonb5]

The archetypal libjpeg has supported 12-bit for a long time, but it's a been a compile-time option, so an application (or distro package) had to choose which bit-depth to support.

[x4e]

Darktable supports it under JPEG2000: https://docs.darktable.org/usermanual/4.0/en/overview/suppor... (Darktable also supports JPEG XL)

[chungy]

JPEG2000 is a different format, just as JPEG XL isn't the same as original JPEG.

[JyrkiAlakuijala]

12 bit jpeg is a different format in practice. Better to move forward than adding support for a new ancient format.

Also, jpegli can support 10+ bits within the old compatible "8 bit" formalism.

[JyrkiAlakuijala]

jpegli can encode and decode 12 bits out of 8 bit jpegs. Or 10-12 bits, more when smoother, less when noisier.

[meindnoch]

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

[adgjlsfhk1]

no. 8 bits isn't enough to cover SRGB without banding artifacts (without dithering).

[meindnoch]

Wait, what? Even with gamma encoding?

[adgjlsfhk1]

yeah (especially in dark areas). On http://www.lagom.nl/lcd-test/gradient.php I can definitely see some in the lower quarter of brightness. It's not glaringly obvious, but it's definitely there.

[JyrkiAlakuijala]

8 bit is not quite enough, not even for the usual sRGB let alone HDR or wide gamut. This is why jpegli is such a promising new option.

[rokweom]

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

[meindnoch]

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

[rokweom]

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

[PaulHoule]

I think so.