immersive-web / webxr

Repository for the WebXR Device API Specification.
https://immersive-web.github.io/webxr/
Other
2.99k stars 386 forks source link

Add a color space as an optional feature for requestSession? #1140

Open Artyom17 opened 4 years ago

Artyom17 commented 4 years ago

AFAIK, there is no way to control which color space is used for rendering. I am not sure we even define the default color space which is used by the experience. However, the experiences may look differently on different devices with different default color spaces. It is kinda a standard de-facto that Web content is using Rec 709 color space. It is relatively narrow color gamut. But VR opens more possibilities for higher dynamic range content with color spaces Rec 2020 or even Rec 2100, especially when newer devices will be able to display all of the colors. More details about the colors could be found here:

https://developer.oculus.com/learn/color-brightness-mastering

Thus, there are two questions. 1) Shouldn't we define the default color space as Rec 709 in the spec? 2) Shouldn't we add a session feature 'colorSpace' for the requestSession and maybe a readonly attribute to get currently set color space?

cabanier commented 4 years ago

Canvas is defined as using sRGB and since WebXR uses a canvas for its compositing, that should be the color space it uses. I'm unsure if there's any colorspace conversion within WebGL itself.

There's a proposal to make the color space of the canvas pixels configurable: https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md

HDR requires that we switch to float values. I'm unsure how much work that would be.

svgeesus commented 3 years ago

Certainly, if WebXR says nothing about the colorspace used, it should at minimum say what the colorspace is! And if that choice is inherited from another specification (if Canvas is mandatory, and canvas is currently sRGB-only) then that dependency should be explicitly noted.

Each XRRenderState has a output canvas, which is an HTMLCanvasElement initially set to null. XRRenderState

Because indeed, Canvas is currently trying to support multiple RGB colorspaces, which would require that WebXR provide a way to select between them, and account for things like increased bits-per-component.

By the way, sRGB has the same primaries and whitepoint as ITU Rec BT.709 but a different transfer function and different viewing conditions. So they should not be treated as equivalent, just closely related. Also, while float or half-float encoding is a reasonable design choice, HDR by itself does not require it. ITU Rec BT.2100 allows both 10 and 12 bits per component (not 8 bits, though), and most broadcast hardware is 10 bit.

The lack of a clear upgrade path for Wide Color Gamut and High Dynamic Range for WebXR was noted in a TAG review - originally in a narrower context, but then expanded to WCG and HDR support throughout the Web platform.

I'm happy to suggest, or review, wording to clarify the colorspace used for WebXR.