- Notifications
You must be signed in to change notification settings - Fork350
Allow out-of-standard-gamut colors with float canvases#4526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
85b3234 to458efacComparekainino0x commentedMar 19, 2024
@ccameron-chromium does this seem right? |
github-actionsbot commentedMar 19, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Previews, as seen when thisbuild job started (7cf11da): |
This comment was marked as outdated.
This comment was marked as outdated.
e8ba5f4 toe7c33a8Comparee7c33a8 tod706a20Compare| <!-- 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: |
kainino0xMar 19, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I wanted to write out an example of the actual blending math, but that ends up demonstrating a completelydifferent problem, which is that you get very different results doing nonlinear blendingin display color space (e.g.in display-p3), vsin srgb.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yes, it gets complicated.
kainino0x commentedMar 19, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
ccameron-chromium left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This behavior seems fine. I'm a bit surprised that we're not allowing this even forrgba16float canvases (since I think that's pretty safe, and we are allowing such canvases to go out of gamut).
| <!-- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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?
Uh oh!
There was an error while loading.Please reload this page.
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 theunpremultiplied 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 Ithink 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'sworse than the canvas format (in either range or precision), the color will be preserved.