Add color space selection to particles sample - #574
beaufortfrancois wants to merge 5 commits into
Conversation
Let users pick the canvas colorSpace (srgb, srgb-linear, display-p3, display-p3-linear) in a new "Color settings" folder. Only color spaces supported by the browser are listed, and a warning is shown when a display-p3 space is selected on a non wide gamut display.
Pass the selected color space to copyExternalImageToTexture and re-copy the image when it changes. Switch the texture to rgba16float to avoid banding with linear color spaces.
| { source: imageBitmap }, | ||
| { | ||
| texture: texture, | ||
| colorSpace: simulationParams.colorSpace as PredefinedColorSpace, |
There was a problem hiding this comment.
Doesn't doing this mean that the colorSpace option will never make a visual difference? webgpu.png is sRGB, so if we color-manage it correctly, it's always going to stay in sRGB.
We should use an image that is Display-P3 or wider (something like https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png from https://webkit.org/blog-files/color-gamut/) so we can see a difference.
But actually, there should* still be no difference because both the texture and the canvas are float formats so they don't get clamped. Would need to change the texture back to unorm.
* I tried hacking in the webkit image (keeping the float format) and it does make a visible difference so I'm not sure if I'm missing something or there is a chrome bug.
There was a problem hiding this comment.
@ccameron-chromium Your help would be appreciated there.
There was a problem hiding this comment.
Doesn't doing this mean that the colorSpace option will never make a visual difference? webgpu.png is sRGB, so if we color-manage it correctly, it's always going to stay in sRGB.
Yeah, I suggested matching the import to the swapchain so that the result would be not be affected by the color space choice.
- I tried hacking in the webkit image (keeping the float format) and it does make a visible difference so I'm not sure if I'm missing something or there is a chrome bug.
CoreAnimation doesn't always behave well with sRGB-linear spaces ... like, it seems to do strange things slightly outside of the sRGB gamut for reasons I don't understand.
The main place where the -linear formats are useful is if you're doing some effect that either needs to be done in linear space or is more convenient to do in linear space. E.g, any sort of physically-based rendering using light transport is always done in linear-float. So if we wanted to model the particle decay using some physical process, then when outputting to the -linear formats, we wouldn't need to convert based to the sRGB transfer function in a final pass.
There was a problem hiding this comment.
We can always have a toggle for unorm/float formats on the input/output or something like that. I just would like to show various options enabling something you couldn't do before.
I put up my hacked version here for testing https://kai.graphics/webgpu-samples/?sample=particles
This branch has not been deployed
3 participants
Let users pick the canvas colorSpace (srgb, srgb-linear, display-p3, display-p3-linear) in a new "Color settings" folder. Only color spaces supported by the browser are listed, and a warning is shown when a display-p3 space is selected on a non wide gamut display.
It also passes the selected color space to copyExternalImageToTexture and re-copy the image when it changes. Switch the texture to rgba16float to avoid banding with linear color spaces.
ChromeStatus entry: https://chromestatus.com/feature/5122501071994880
Try it live in https://webgpu.github.io/webgpu-samples/?sample=particles
FYI @ccameron-chromium