Open Bug 1626624 Opened 6 years ago Updated 4 months ago

Support Wide Gamut Color in CSS with Display-P3

Categories

(Core :: Graphics, enhancement)

Product:
Core
Component:
Graphics
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
firefox76 --- affected

People

(Reporter: afmenez, Unassigned, NeedInfo)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-safari, Whiteboard: [platform-feature][webcompat:risk-moderate])

CSS Color Module Level 4 introduced syntax to use Display-P3 color space on the web:
color: color(display-p3 1 0.5 0)

This is already implemented in WebKit:
https://webkit.org/blog/10042/wide-gamut-color-in-css-with-display-p3/

I have already linked a bug for media-query support, but a separate bug for the Inspector is probably needed to.

Severity: normal → S3

Do we have support for wide-gamut color ranges on the gfx side even, or do we just convert to sRGB for rendering anyway?

Currently we convert images to the display profile and CSS colors remain uncorrected. On macOS we always use sRGB as the display profile and the OS will convert our combined sRGB content to the display profile for us.

It seems like it would be a reasonable start to convert wide gamut colors to sRGB.

If we end up converting colors into sRGB for rendering to screen and they are outside of sRGB gamut, we need to map them according to the spec here: https://drafts.csswg.org/css-color-4/#css-gamut-mapping

Blocks: 1815186
Depends on: 1823363
Duplicate of this bug: 1830268

1830268 is now resolved, shouldn't this issue be closed too?

Why? Bug 1830268 has been closed as a duplicate of this bug.

It may be worth revisiting the priority and severity here now that Figma supports this, as it is also an interop2022/2023 item.

Flags: needinfo?(emilio)

My understanding is that the CSS part of this seems basically done. The remaining bits seem actually layout/rendering, where for non-sRGB colors:

  • For sRGB displays we need to map to the sRGB gamut.
  • For non-sRGB displays we ideally carry the colors all the way across the pipeline.

Tiaan is my understanding correct? If so, should this move to either layout / graphics? I think this is worth doing sooner rather than later tho.

Flags: needinfo?(emilio) → needinfo?(tlouw)

Yes we have the colors now in different color spaces and can convert to a device color space for rendering, but right now the rendering back ends (webrender, cairo at least) doesn't seem to support anything other than sRGB, so this work should move there.

Flags: needinfo?(tlouw)
Component: CSS Parsing and Computation → Graphics
No longer blocks: css-color-4
No longer duplicate of this bug: 1830268

I tried enabling the following in about:config but its not working for me:

gfx.color_management.display_profile = /System/Library/ColorSync/Profiles/Display P3.icc
gfx.color_management.mode = 1
gfx.color_management.native_srgb = false

I should be more specific, when I go to this page I don't see a different in the P3 and non-P3 colors but do on Chrome and Safari: https://codepen.io/hashtag_dino/pen/gEvJQa

(In reply to GolDonMomotaro from comment #13)

I should be more specific, when I go to this page I don't see a different in the P3 and non-P3 colors but do on Chrome and Safari: https://codepen.io/hashtag_dino/pen/gEvJQa

Yeah, more things need to be hooked up for that to work

Like what?

ToDeviceColor needs support for displayP3 colors:
https://searchfox.org/mozilla-central/rev/8461ad1fc943ac560414322b66de5929ef10f706/gfx/thebes/gfxUtils.cpp#1783 and then the style system needs to be hooked up to use the displayP3 ToDeviceColor variant

Whiteboard: webcompat:risk-moderate

Also there's something wrong about color management in canvas: https://bugzilla.mozilla.org/show_bug.cgi?id=1939259

(In reply to Tiaan Louw from comment #10)

Yes we have the colors now in different color spaces and can convert to a device color space for rendering, but right now the rendering back ends (webrender, cairo at least) doesn't seem to support anything other than sRGB, so this work should move there.

Do you have a link to the bug for supporting rendering high-gamut colours in WebRender?

Flags: needinfo?(tlouw)

Doesn't look like there is one specific for it, but this might be better answered by the graphics team.

Flags: needinfo?(tlouw) → needinfo?(jmuizelaar)

WebRender is already wide gamut on Mac (the whole OS uses P3), on Windows it's more complicated where WCG displays that do not use Advanced Color Management work fine, but if you turn on either HDR or ACM (which are both the same thing in the compositor), Firefox strictly adheres to sRGB and loses the WCG functionality.

Implementing HDR CSS rendering would cover both the ACM and HDR display modes on Windows, so that's the best avenue to address it in my opinion, earliest ETA to deliver that is H1 2026 though unless we re-prioritize.

We may be able to deliberately choose to render everything in P3 and send that to the Windows DWM compositor and lose some precision on sRGB content though, which might be an alternative with no additional rendering cost.

Does that answer the question?

Flags: needinfo?(tlouw)
Duplicate of this bug: 1928864

A useful test case for this in the wild is given in https://bugzilla.mozilla.org/show_bug.cgi?id=1928864#0

(In reply to Ashley Hale [:ahale] from comment #20)

WebRender is already wide gamut on Mac (the whole OS uses P3), on Windows it's more complicated where WCG displays that do not use Advanced Color Management work fine, but if you turn on either HDR or ACM (which are both the same thing in the compositor), Firefox strictly adheres to sRGB and loses the WCG functionality.

Implementing HDR CSS rendering would cover both the ACM and HDR display modes on Windows, so that's the best avenue to address it in my opinion, earliest ETA to deliver that is H1 2026 though unless we re-prioritize.

We may be able to deliberately choose to render everything in P3 and send that to the Windows DWM compositor and lose some precision on sRGB content though, which might be an alternative with no additional rendering cost.

Does that answer the question?

There are still some quite severe issues on color management in traditional SDR rendering for a long time, will they get fixed?

Also we shouldn’t render everything in Display P3 but a larger gamut range such as scRGB or ACEScg, since there might be pictures(mostly photos shot by camera) that has even larger gamut range than Display P3, and chromium is using scRGB now.

I would like to use scRGB in RGBA16F for the entire app and only have optimizations for speed in some places, which would deliver consistent WCG and HDR everywhere but that is an ongoing discussion topic.

I guess what I'm trying to understand is: why does oklch.com report that Firefox does not support P3.

For example:
https://oklch.com/#0.7735,0.1554,213,100

Hi. oklch.com author here.

oklch.com renders "no P3 support" based on window.matchMedia('(color-gamut:p3)').match check by media query.

https://searchfox.org/mozilla-central/rev/601256c3cc6f397b018995810fd3f586570f50ee/widget/Screen.cpp#119-123 well yeah that would do. We need to plumb the color gamut of the screen from widget.

From a CSS point of view the colors can be specified, parsed, computed, etc., but once it goes to be rendered on screen I'm not sure how it ends up there.

Flags: needinfo?(tlouw)

(In reply to Ashley Hale [:ahale] from comment #24)

I would like to use scRGB in RGBA16F for the entire app and only have optimizations for speed in some places, which would deliver consistent WCG and HDR everywhere but that is an ongoing discussion topic.

Btw I have to warn you that sRGB, scRGB and Display P3 seems all using gamma 2.2 for reference display rather than piecewise sRGB transfer function. More information here: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30

(In reply to wiagn233 from comment #29)

(In reply to Ashley Hale [:ahale] from comment #24)

I would like to use scRGB in RGBA16F for the entire app and only have optimizations for speed in some places, which would deliver consistent WCG and HDR everywhere but that is an ongoing discussion topic.

Btw I have to warn you that sRGB, scRGB and Display P3 seems all using gamma 2.2 for reference display rather than piecewise sRGB transfer function. More information here: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30

Seems my previous comment is wrong, Display P3 didn't do this, only sRGB/scRGB have this special behavior.

(In reply to wiagn233 from comment #30)

(In reply to wiagn233 from comment #29)

(In reply to Ashley Hale [:ahale] from comment #24)

I would like to use scRGB in RGBA16F for the entire app and only have optimizations for speed in some places, which would deliver consistent WCG and HDR everywhere but that is an ongoing discussion topic.

Btw I have to warn you that sRGB, scRGB and Display P3 seems all using gamma 2.2 for reference display rather than piecewise sRGB transfer function. More information here: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30

Seems my previous comment is wrong, Display P3 didn't do this, only sRGB/scRGB have this special behavior.

After checking the scRGB spec(IEC 61966-2-2), I found out that by default scRGB uses linear color space(unless you are using non-linear space scRGB-nl), so that scRGB is not affected either. And we have to use power 2.2 curve when converting non-linear sRGB image to linear scRGB space.

About Display P3, Troy has confirmed that apple are doing the same as sRGB, but only in some cases. Maybe we need to check Webkit source code to find out how they convert Display P3 image/CSS color to linear blending space and follow that behavior in Firefox.

Hello, I have a question: How does firefox currently get monitor characteristics from host OS? Will it try to get monitor ICC? Or just primaries+white point+TRC?

Flags: needinfo?(ahale)

(In reply to wiagn233 from comment #31)

(In reply to wiagn233 from comment #30)

(In reply to wiagn233 from comment #29)

(In reply to Ashley Hale [:ahale] from comment #24)

I would like to use scRGB in RGBA16F for the entire app and only have optimizations for speed in some places, which would deliver consistent WCG and HDR everywhere but that is an ongoing discussion topic.

Btw I have to warn you that sRGB, scRGB and Display P3 seems all using gamma 2.2 for reference display rather than piecewise sRGB transfer function. More information here: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30

Seems my previous comment is wrong, Display P3 didn't do this, only sRGB/scRGB have this special behavior.

After checking the scRGB spec(IEC 61966-2-2), I found out that by default scRGB uses linear color space(unless you are using non-linear space scRGB-nl), so that scRGB is not affected either. And we have to use power 2.2 curve when converting non-linear sRGB image to linear scRGB space.

About Display P3, Troy has confirmed that apple are doing the same as sRGB, but only in some cases. Maybe we need to check Webkit source code to find out how they convert Display P3 image/CSS color to linear blending space and follow that behavior in Firefox.

Update about Display P3: After emailing Dean Jackson from Apple, we know that they are using sRGB transfer function in webkit for Display P3, but since they are faking actual power 2.2 TRC curve as sRGB curve in TRC tags of the ICC file for their monitors' factory calibration, I think we still need to use power 2.2 function for Display P3 content degamma.

(In reply to wiagn233 from comment #32)

Hello, I have a question: How does firefox currently get monitor characteristics from host OS? Will it try to get monitor ICC? Or just primaries+white point+TRC?

Currently Firefox converts all images and CSS colors using the ICC profile to deliver pixels in a colorspace that is specific to the display.

I've seen bug reports that make me think it is rejecting ICC profiles for HDR monitors due to negative coefficients, I'm not yet familiar with the ICC profile format and will need to look into this sometime.

To be clear, half the reason for using scRGB is that we don't have to deal with monitor ICC profiles at all because the OS handles that part - using scRGB means we only need to think about content colorspaces (i.e. sRGB->scRGB, Rec709->scRGB, displayP3->scRGB, etc), and means we don't have to worry about different monitors having different ICC profiles, and don't have to worry about corrupted ICC profiles as it is up to the OS to make a judgment on what is/isn't valid (currently we sometimes honor a corrupted ICC profile that the OS is holding on to but ignoring as a practical matter, people file bugs about that from time to time). Importantly this also means we wouldn't have to think about inverting an ICC profile (which we currently do for some purposes).

Flags: needinfo?(ahale)

(In reply to Ashley Hale [:ahale] from comment #34)

(In reply to wiagn233 from comment #32)

Hello, I have a question: How does firefox currently get monitor characteristics from host OS? Will it try to get monitor ICC? Or just primaries+white point+TRC?

Currently Firefox converts all images and CSS colors using the ICC profile to deliver pixels in a colorspace that is specific to the display.

I've seen bug reports that make me think it is rejecting ICC profiles for HDR monitors due to negative coefficients, I'm not yet familiar with the ICC profile format and will need to look into this sometime.

To be clear, half the reason for using scRGB is that we don't have to deal with monitor ICC profiles at all because the OS handles that part - using scRGB means we only need to think about content colorspaces (i.e. sRGB->scRGB, Rec709->scRGB, displayP3->scRGB, etc), and means we don't have to worry about different monitors having different ICC profiles, and don't have to worry about corrupted ICC profiles as it is up to the OS to make a judgment on what is/isn't valid (currently we sometimes honor a corrupted ICC profile that the OS is holding on to but ignoring as a practical matter, people file bugs about that from time to time). Importantly this also means we wouldn't have to think about inverting an ICC profile (which we currently do for some purposes).

Thanks for reply. I think we need to implement support for using parametric characteristics before we could land scRGB output support, since most wayland compositors does not support that. More information here: https://bugs.kde.org/show_bug.cgi?id=504065

Flags: needinfo?(ahale)

I'm not sure I follow.

If you're referring to the existing non-scRGB case where our qCMS system interprets an ICC profile, it's easy to make our qCMS code consume other data structures for Wayland in lieu of the missing ICC profile, I looked up https://wayland.app/protocols/color-management-v1#wp_image_description_info_v1 and I assume you are saying the icc_file is never sent in typical usage, so we just need to interpret the primaries, tf_power, luminances, target_primaries, target_luminance and set up qCMS based on those values instead of an ICC file - that seems totally fine, and is still capable of wide color gamut (i.e. if the primaries are wider, it's no longer sRGB and can represent a wider color gamut) but not HDR.

In the scRGB case the goal is to send image data to the compositor in a standard colorspace (scRGB or HDR10 or displayP3 are reasonable options if the compositor understands them), so no awareness of display color profiles is involved in the browser. If Wayland does not consistently support standard colorspaces like this, then we need to either fall back to the qCMS system and not attempt to do HDR, or we need to add a postprocess to apply the desired color correction and pixel format conversion before sending it to the compositor.

Flags: needinfo?(ahale)

(In reply to Ashley Hale [:ahale] from comment #36)

I'm not sure I follow.

If you're referring to the existing non-scRGB case where our qCMS system interprets an ICC profile, it's easy to make our qCMS code consume other data structures for Wayland in lieu of the missing ICC profile, I looked up https://wayland.app/protocols/color-management-v1#wp_image_description_info_v1 and I assume you are saying the icc_file is never sent in typical usage, so we just need to interpret the primaries, tf_power, luminances, target_primaries, target_luminance and set up qCMS based on those values instead of an ICC file - that seems totally fine, and is still capable of wide color gamut (i.e. if the primaries are wider, it's no longer sRGB and can represent a wider color gamut) but not HDR.

As far as I know, both Mutter(GNOME) and Kwin(KDE) don't support icc_file. Only Weston supports it.

In the scRGB case the goal is to send image data to the compositor in a standard colorspace (scRGB or HDR10 or displayP3 are reasonable options if the compositor understands them), so no awareness of display color profiles is involved in the browser. If Wayland does not consistently support standard colorspaces like this, then we need to either fall back to the qCMS system and not attempt to do HDR, or we need to add a postprocess to apply the desired color correction and pixel format conversion before sending it to the compositor.

Seems Mutter, Kwin and Weston supports all the colorspaces listed in protocol spec, so I don't think this is a problem.

Flags: needinfo?(ahale)
Whiteboard: webcompat:risk-moderate → [platform-feature][webcompat:risk-moderate]
You need to log in before you can comment on or make changes to this bug.