Allow out-of-standard-gamut colors with float canvases #4526
Conversation
kainino0x
force-pushed
the
out-of-gamut-sometimes-valid
branch
from
85b3234
to
458efac
Compare
|
@ccameron-chromium does this seem right? |
|
Previews, as seen when this build job started (7cf11da): |
This comment was marked as outdated.
This comment was marked as outdated.
kainino0x
changed the title
kainino0x
force-pushed
the
out-of-gamut-sometimes-valid
branch
from
e8ba5f4
to
e7c33a8
Compare
kainino0x
force-pushed
the
out-of-gamut-sometimes-valid
branch
from
e7c33a8
to
d706a20
Compare
| <!-- POSTV1(#4108): add example for XR formats, which *probably* handle this --> | ||
| </table> | ||
|
|
||
| Visible results may be undefined because the value could be lost at different steps of display: |
There was a problem hiding this comment.
I wanted to write out an example of the actual blending math, but that ends up demonstrating a completely different problem, which is that you get very different results doing nonlinear blending in display color space (e.g. in display-p3), vs in srgb.
There was a problem hiding this comment.
Yes, it gets complicated.
| <!-- POSTV1(#4108): add example for XR formats, which *probably* handle this --> | ||
| </table> | ||
|
|
||
| Visible results may be undefined because the value could be lost at different steps of display: |
There was a problem hiding this comment.
Yes, it gets complicated.
| regardless of the canvas's {{GPUCanvasConfiguration/format}}. | ||
|
|
||
| However, when a ({{GPUCanvasAlphaMode/"premultiplied"}}) canvas containing such a value is | ||
| displayed *on screen*, the visible result for the entire canvas is undefined. |
There was a problem hiding this comment.
Checking that I understand.
Consider a canvas that is premultiplied, rgba16float, srgb being displayed on a P3 monitor.
If the value [0.52, 0, 0, 0.5] is written to the canvas, and the canvas is displayed, then the result is undefined even though it's within the gamut of the display, because of various machinations that might happen throughout the display pipeline.
This seems reasonable to me. Would the idea be to make this valid when in extended mode?
kainino0x
added
the
needs-cts-issue
The spec previously said that it was undefined behavior to display "out-of-gamut premultiplied RGBA values" (R/G/B > A).
But that definition overlooked some cases. We intended to allow using an rgba16float srgb canvas to display wider-than-srgb colors, but such colors would according to the current definition be "out-of-gamut premultiplied RGBA values" (regardless of whether they're opaque like
[1.04, 0, 0, 1]or transparent like[0.52, 0, 0, 0.5]).This replaces that concept with "out-of-range premultiplied RGBA values", which is when the unpremultiplied equivalent of the color can't be represented in the format used for the color (e.g. premul
[0.52, 0, 0, 0.5]inrgba8unorm). I've written it this way because I think it will be valid for #4108 as well if we ever get that [EDIT: fixed link to point to correct issue]. The idea is that as long as the implementation doesn't use any intermediate format that's worse than the canvas format (in either range or precision), the color will be preserved.