1847503 - [css-color] Implement gamut mapping for out of range colors

Status: NEW

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Tiaan Louw]

When converting colors to different color spaces, the resulting color might sometimes be out of gamut for the target color space. This is usually ok, but once the color is used to render elements to the screen (or printer, etc), it needs to be mapped into the target color space's gamut range.

For instance, lch(79.4% 62.5 55.71) converted to srgb (which is used to render to the screen at the moment) is color(srgb 1.075 0.665 0.396) where the red component is out of gamut. Gamut mapping this color according to the specification would yield color(srgb 1.0 0.683 0.455) which is in gamut and ready to render to the screen.

See: https://drafts.csswg.org/css-color-4/#gamut-mapping

Comment 1

[romainmenke]

The specification has had some updates in the past few months and a new reference to gamut mapping is converting certain colors to black or white when gamut mapping for display

https://drafts.csswg.org/css-color/#specifying-lab-lch

If the lightness of a Lab color (after clamping) is 0%, or 100% the color will be displayed as black, or white, respectively due to gamut mapping to the display.

Comment 2

[Tiaan Louw]

Attachment: WIP: Bug 1847503 - Map colors into gamut limits before rendering. r=emilio,#layout

When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.

Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping

The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/667d97f09248
Map colors into gamut limits before rendering. r=layout-reviewers,emilio

Comment 4

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/42606 for changes under testing/web-platform/tests

Comment 5

[Iulian Moraru]

Backed out for causing reftest failures on anim-css-fill-overflow-1-by.svg.

• Push with failures

• Failure log

• Backout link

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 7

[Tiaan Louw]

After implementing the gamut mapping, I started getting a failure in the SVG animations using SMIL.

According to the SMIL spec, out of gamut colors should just be clipped, but now that we're implementing gamut mapping, it makes more sense to gamut map the results.

The spec:
https://www.w3.org/TR/SVG11/animate.html

19.2.15 The ‘animateColor’ element
...
Out of range color values can be provided, but user agent processing will be implementation
dependent. User agents should clamp color values to allow color range values as late as
possible, but note that system differences might preclude consistent behavior across
different systems.

The specific test and reference is here:
https://searchfox.org/mozilla-central/rev/eadfec923e2b9c927ade8d0dd4f08a82da50a8a9/layout/reftests/svg/smil/style/anim-css-fill-overflow-1-by.svg
https://searchfox.org/mozilla-central/rev/eadfec923e2b9c927ade8d0dd4f08a82da50a8a9/layout/reftests/svg/smil/style/anim-css-fill-overflow-1-ref.svg

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e5e1bc9736a5
Map colors into gamut limits before rendering. r=layout-reviewers,emilio

Comment 9

[Narcis Beleuzu [:NarcisB]]

Backed out for reftest failures on anim-css-floodcolor-overflow-1-from-by.svg

Backout link: https://hg.mozilla.org/integration/autoland/rev/cc2d7a60e797ccda49d1a49206bcded220dd6c4b
Log link: https://treeherder.mozilla.org/logviewer?job_id=434511567&repo=autoland&lineNumber=8110

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09a6e2a57a02
Map colors into gamut limits before rendering. r=layout-reviewers,emilio

Comment 12

[Norisz Fay [:noriszfay]]

Backed out for causing canvas failures on canvas-display-p3-drawImage.https.html

Backout link

Push with failures

Failure log

This is also failing: https://treeherder.mozilla.org/logviewer?job_id=434599606&repo=autoland&lineNumber=6515

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 14

[Robert Longson [:longsonr]]

How does this interact with feDisplacementMap filters? https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feDisplacementMap I would expect in2 not to be affected as it's supposed to work on the raw pixel values of the image. If those are corrected then you'll get different displacements on different devices. See also bug 500321

Comment 15

[Tiaan Louw]

I'm not 100% on the workings of feDisplacementMap, but this gamut mapping is only done for colors, not images.

Every incoming color for SVG is converted to sRGB, e.g. <rect width="2" height="2" style="fill: color(display-p3 1 0 0);"/>, the fill color will be converted to: rgb(98.23% 21.8% 0%). So any any "raw pixel value" should be in sRGB if gamut mapping is not applied, you will work with "invalid" colors.

Comment 17

[Herbert Snorrason]

This is an exact match for what I was asking for, so I think it's better to mark the duplicate to here, rather than bug 1626624. The existence of this bug seems to suggest that the resolution of bug 1830268 was in error.