Chrome Jpegxl Issue Reopened

That video is clearly not encoded correctly. If it were the levels would match the background, given there is no actual HDR content visible in that video frame.

Anyway, even if the video was of a lovely nature scene in proper HDR, you might still find it jarring compared to the surrounding non-HDR desktop elements. I might too, depending on the specifics.

However, like I said, it's up to the browser to handle this.

One suggestion I saw mentioned by some browser devs was to make the default to tone map HDR if the page is not viewed in fullscreen mode, and switch to full HDR range if it is fullscreen.

Even if that doesn't become the default, it could be a behavior the browser could let the user select.

WebP is much more limiting than JPEG XL. in lossy mode WebP has forced 4:2:0 chroma subsampling, supports only 8 bit per channel colors (really only about 7.8 bits, because thanks to WebP being tv-range the values aren't in a 0-255 range but in a 16-235 range, causing even more color banding than 8 bit per channel already has), no HDR, a maximum resolution of 16385 x 16385 making it unsuitable for larger images...

JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc.

WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.

In a modern image chain, capture is more often than not HDR.

These images are then graded for HDR or SDR. I.e., sacrifices are made on the image data such that it is suitable for a display standard.

If you have an HDR image, it's relatively easy to tone-map that into SDR space, see e.g. BT.2408 for an approach in Video.

The underlying problem here is that the Web isn't ready for HDR at all, and I'm almost 100% confident browsers don't do the right things yet. HDR displays have enormous variance. From "Slightly above SDR" to experimental displays at Dolby Labs. So to display an image correctly, you need to render it properly to the displays capabilities. Likewise if you want to display a HDR image on an SDR monitor. I.e., tone mapping is a required part of the solution.

A correctly graded HDR image taken of the real world will have like 95% of the pixel values falling within your typical SDR (Rec.709/sRGB) range. You only use the "physically hurt my eyes" values sparingly, and you will take the room conditions into consideration when designing the peak value. As an example: cinemas using DCI-P3 peaks at 48 nits because the cinema is completely dark. 48 nits is more than enough for a pure white in that environment. But take that image and put it on a display sitting inside during the day, and it's not nearly enough for a white. Add HDR peaks into this, and it's easy to see that in a cinema, you probably shouldn't peak at 1000 nits (which is about 4.x stops of light above the DCI-P3 peak). In short: your rendering to the displays capabilities require that you probe the light conditions in the room.

It's also why you shouldn't be able to manipulate brightness on an HDR display. We need that to be part of the image rendering chain such that the right decisions can be made.

> You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail.

I'm not sure what you mean. They appear to act like any other photo in the interface. You can view them and they're visible in the thumbnail view, but maybe I'm misinterpreting what you mean?

I didn't realize WebP was limited-RGB in addition to 4:2:0. According to RFC 9649, this is accurate. While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB:

> The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.