Wide Gamut Color in CSS with Display-P3 | Hacker News Reader

Wide Gamut Color in CSS with Display-P3

webkit.org

78 pointschmaynard44 comments

If someone needs to read up on color profiles: https://bjango.com/articles/colourmanagementgamut/

Eg. important to configure ones design tools like Sketch and Photoshop correctly so that it interprets RGB values as intended rather than just in the current color profile

Neat, but I find it hard to believe devs are going to reach for this verbose format without a default fallback.

hsl is a much nicer syntax for humans to describe color than rgb channels.

I'm sure there are good reasons under the hood, but why that syntax over something like:

``` header { color: hsl(42, 70%, 50%); color: hsl(display-p3 42, 70%, 50%); } ```

Also, I'm not understanding why HSL doesn't automatically inherit the P3 color space without any code changes. It shouldn't require any additional syntax, the HSL model is describing abstracted color values, unlike HEX or RGB which are hardcoded values.

Unless I'm not understanding this correctly. If that's correct, it seems strange and sloppy to require the display-p3 definition.

Because an HSL value translated directly to sRGB will look different when translated to P3. The color spaces themselves define different ranges of R, G, and B. The only backwards-compatible method to derive P3 colors from HSL values would be with saturation and lightness values greater than one.

HSL is not really abstracted. Instead, it is just a different way of specifying RGB values. So you can't have HSL switch to the P3 color space, because you would end up with color shifts.

In other words, same HSL => same RGB, and same RGB but different space => often a different color.

If you need color profiles, then you are beyond tweaking the HSL values by hand in CSS. The main value in using color profiles is so you can use an exact color match with an image using that profile, and if you're doing that, it's more natural to have an RGB value. So, providing HSL doesn't really add any value here, as far as I can tell.

So, does this gracefully degrade to sRGB? If so, how does one set the rendering intent for degrading to sRGB? One needs to be able to choose either relative colorimetric or perceptual (absolute colorimetric and presentation are fairly uncommon), but which one depends on the intent of the designer.

Or is one expected to provide two different color values for every element? That would be tedious.

According to what I read in the article, you have to provide the sRGB fallback yourself. I suppose this is only a true annoyance if you're writing CSS by hand (like I do), but I hear most people these days use Less or some other CSS preprocessor that can easily handle this.

The article mentions the manual fallback for when the browser does not support the syntax, but I wonder what happens when Chrome gets updated to support color() but is used on a device that does support Wide Gamut Color. I guess the safest thing would be to still treat it as an invalid value and require manual fallback.

Chrome should, per the spec, drop the entire rule

Media Queries are the right answer for that case (assuming the default translation to SRGB is unsatisfactory.)

This may already happen on Safari and Mac without support for Wide Gamut Color. In that case, the P3 color is converted to sRGB, which typically means clamping to sRGB.

Glad to hear there are others out there practicing this fine art haha

You’re expected to provide two color declarations for every element. This is normal practice for backwards-compatibility in web design, so there’s nothing surprising in the method. Frameworks that generate CSS will quickly learn to handle this for us and it’ll be fine.

If your monitor doesn't cover the entirety of P3, it does "degrade" to the closest color your monitor is capable of showing. This isn't necessary sRGB — most monitors that don't fully support P3 yet still support gamuts wider than sRGB.

I don't know whether relative or perceptual colorimetric rendering intent is used.

You can open https://codepen.io/NV/pen/XLOOdE in Safari Technology Preview and check how it looks on various monitors.

There is no such thing as a monitor degrading. The monitor displays the color values it receives, period. It does not do profile conversion. It does not know anything about rendering intent. It doesn't even know about color profiles. It knows: Display this RGB value for this pixel. That's it.

It is up to the software driving the display to choose appropriate color values. That means that if a monitor has the Display-P3 gamut, then it is up to the OS or browser to know this, and send appropriate color values when viewing sRBG data such that the colors are not oversaturated.

Yes, graphics cards can store LUT tables to linearize the RGB curves to neutralize grays. But this is not gamut mapping. Profiling is a process that happens after a display is linearized, and that profile is loaded into the OS.

I'm in the color print industry. I know color management intimately.

This all gets interesting when mixing sRGB, Display-p3 or Lab colors in gradients and animations. There's an open issue about it at W3C: https://github.com/w3c/csswg-drafts/issues/4647

I think Safari currently fails to display such gradients.

I made an sRGB to Display-P3 gradient and it worked well for me in Safari: https://codepen.io/NV/pen/GRJvYzQ.

You are right! I had tried it in SVG, where solid P3 works, but gradient P3 fails: https://jsfiddle.net/6pL12ct0/

This kind of thing cracks me up. It's 2020. We live in the future.

I have a HDR, wide-gamut, 10-bit, calibrated display.

Send me a non-sRGB or HDR still image file that will display correctly. That is, with the right colours, in wide gamut, with or without HDR.

You can't because I haven't specified what platform or application I'm using.

Even if I did specify, you probably can't create such a file. For example, it's currently borderline impossible to create a HEIC file on Windows, even though it would allow 10-bit wide-gamut files to be sent to an Apple IOS user and be displayed correctly, which is at least something. Adobe Lightroom refuses to support arbitrary colour spaces on export (why!?), and doesn't include Display P3 in the fixed list that it does support.

But if you do somehow manage to create a HEIC file (or any wide-gamut file format) on Windows, it will show it incorrectly anyway, but not in all apps. Some will work. But only if you manually configure a profile for your monitor. But then your desktop colours will shift, which will make your previously valid sRGB CSS colours display incorrectly with sRGB stretched to the wide gamut because fuck you, that's why.

To my knowledge it is currently impossible to solve any such problem. Colour management in the Windows, Linux, XBox, PlayStation, and Android space is an unmitigated clusterfuck. Apple meanwhile is pretending that Display P3 is the only wide gamut that exists, because they use it.

One CSS attribute implemented on one platform with one usable colour space will not solve this. It won't even begin. It's like reading an article about the finer points of cake decoration in the midst of a famine. It feels almost insulting. Like I should feel ashamed for starving, and not being one of the rich elite that can afford cake. But nobody has cake, they're all pretending.

Right now, in 2020, the only still image interchange format that more or less works is an sRGB, SDR, 8-bit JPEG. You can't have anything else. No 10-bit. No other gamut. No HDR. No compression better than the one invented in 1992.

Okay fine, I admit it. There is a way to solve this problem. Download DaVinci Resolve and create a new movie. Import your HDR image as a still image "video" clip. Export the single frame movie, or a slideshow if you please, in whatever HDR format you prefer. Upload to YouTube. Share YouTube link.

This, seriously is it. This is what we've all achieved.

Congratulations, Microsoft (#2 biggest company), Apple (#3), and Alphabet Group (#4). Your stewardship of web standards and email clients has resulted in this.

What about giving colors in 16bpp in linear space instead?

That covers way more displays and future ones, no?

No, because this expands colours to ones that cannot be expressed with sRGB, no matter if it's encoded as 16bit linear, or with the sRGB transfer function. You cannot express a hue outside the Rec.709 triangle, no matter how much precision you add (1).

Display-P3 uses points in CIE xyz space for its RGB channels that are farther apart than sRGB, allowing it to express more hues, which sRGB monitors and colours cannot. It's still not the full spectrum humans can see, but it's much better.

(1) technically you can, if you allow channel values to be negative, but that breaks compositing.

> It's still not the full spectrum humans can see

In case anyone wonders why colour spaces don't typically try to cover the full spectrum, there's two problems. One is that it may be difficult to reproduce consistently, but the other problem is that it's not a neat triangle, so to represent it completely as RGB you would have large regions of undefined space.

Another issue is that as you increase the gamut, you decrease precision. So you sometimes see wide gamuts like scRGB only used with higher precision images.

I don’t see that as a problem. The color would be undefined for humans, but they would still be colors. It would make sense to have them if only to be able to perform operations on them and retain quality (like working with HDR/raw images even if almost everybody will see them in sRGB).

I should have said floats, yeah. GPUs shaders work in many cases with 32-bit floats per channel in linear space, right? I don’t see why browsers couldn’t support colors with that precision considering they may be rendering with the GPU anyway (perhaps with another profile, yes).

Browsers could clamp them to sRGB on parsing for the moment and add proper functionality later.

That just describes how precise of a value between 0 and 100% for each Red, Green and Blue channel you can define, it doesn’t change what Red, Green and Blue a 100% actually represents.

The color profile defines what your definition actually represents and translates your 0-100% value to an actual color on the display.

What about 16-bit or 32-bit floats in linear space? They can go way below and above the [0, 1] range while maintaining a lot of precision in that important range.

The latest CSS Color spec includes support for Lab colors in linear space. It covers all possible colors. The syntax supports decimal numbers, so you can have as much precision as you want (depending how much the browser supports internally): lab(75.12321% 30.4124 -12.32434353)

In addition to supporting all colors, it also supports HDR (very bright pixels) by allowing the lightness to go above 100%. So, this is very bright red: lab(400% 80 70).

Most design software (Photoshop, Affinity Designer..) can display colors as Lab values and those can be used in CSS. Since lab colors are not intuitive for humans, CSS also supports Lch (lightness, chroma, hue), which is more human friendly.

Browser vendors are currently adding Lab support to their browsers.

https://www.w3.org/TR/css-color-4/#lab-colors

Thanks a lot for this answer, very informative. I was not aware of Lab coming to browsers.

This is nice, but can I use it with an HDR monitor without forking over $7000 for an Apple Pro Display XDR?

I haven't been able to confirm whether or not Mac OS Catalina actually supports any third party HDR monitors over HDMI.

I have the Asus PG27UQ 4K HDR monitor and my 2019 MacBook Pro only outputs 4K 30Hz 8bpc over the official Apple HDMI adapter[1], while my 2019 XPS 13 2-in-1 outputs 4K 60Hz 10bpc over this same Apple adapter.

[1] https://www.apple.com/shop/product/MUF82AM/A/usb-c-digital-a...

They mention the "LG UltraFine 5K Display" on the page, maybe it's the only one supported? Maybe there's more

I have some sort of Dell at home that I believe I tested and works properly.

But then again I’m using DisplayPort. I don’t know why people are so insistent on using HDMI and being surprised it doesn’t work as well.

I save the DisplayPort port on this monitor for my Windows desktop because Mac OS doesn't appear to output the 4K 98Hz HDR that the Asus PG27UQ naively supports over DisplayPort 1.4.

Catalina will support any HDR monitor. You would just need a HDMI splitter and run it into your monitor.

Alternatively, pop a Blackmagic Decklink 4k into a PCIe chasis and run it out of one of the thunderbolt 3 ports. I do this on my HDR OLED and it works nicely.

Are you able to get a 4K HDR signal through the official Apple HDMI adapter to your HDR OLED display, or only through your Blackmagic Decklink 4K?

I am using the official Apple HDMI adapter with the Asus PG27UQ.

My Decklink Mini 4k was under $200 and does the job.

I don't know about your Apple adapter. Were it not working, then I would look at getting a HDCP splitter midway in the chain.

Display-P3 is not HDR.

It is just a wider gamut, so wider range of colours but otherwise still SDR. It has the same tone curve (gamma function) as sRGB.

> There are also numerous devices that support Display-P3 color space but currently have no browsers that support Display-P3 in CSS

I wonder if someone could build WebKit for them.

Doesn't Google cherry pick these changes into Blink anyway?

Trying this in Safari I just see “unsupported property” in the inspector?

Maybe it's because your monitor doesn't support it?

Are you using Safari Technology Preview? Web Inspector support was added in STP 97. Before that `color: color(display-p3 0 1 0)` showed as unsupported property in Web Inspector.

Thanks, seems that was it. I had only checked it in regular Safari.

Reply on news.ycombinator.com