Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebGPU, WCG and HDR #8

Open
tidoust opened this issue Aug 25, 2020 · 7 comments
Open

WebGPU, WCG and HDR #8

tidoust opened this issue Aug 25, 2020 · 7 comments
Assignees

Comments

@tidoust
Copy link
Member

tidoust commented Aug 25, 2020

The newly created GPU for the Web Working Group develops the WebGPU API, a more modern version of WebGL (raised in #2). The draft spec does not mention "color spaces". Possibly relevant bits of info:

@svgeesus
Copy link
Contributor

svgeesus commented Aug 29, 2020

Thanks for raising this, @tidoust

Agree that no mention of the colorspace is a big issue. Is it assumed to be the native display colorspace, so you get different colors on different screens? Surely not.

However, one nice thing I noticed straight away

dictionary GPUColorDict {
    required double r;
    required double g;
    required double b;
    required double a;
};
typedef (sequence<double> or GPUColorDict) GPUColor;

so compared to Canvas or the CSS Object Model or the HTML "simple color" (all of which are still stuck in 8 bits per component) using double is a big win there. Enough space for the precision requirements of WCG and probably, depending on how it is defined, HDR as well.

But it does need to be defined:

  • what is the range? Nominal 0 to 1 for SDR?
  • what is the colorspace (rgbw chromaticities)?
  • what is the transfer function ( gamma-encoded or linear)?
  • if media (diffuse) white is 1.0 1.0 1.0 then where is highlight white?

How do those colors get mapped to eventual display coordinates for SDR and for HDR displays?

@palemieux
Copy link
Contributor

The section in the report needs to be expanded.

@ccameron-chromium
Copy link
Collaborator

@svgeesus
Copy link
Contributor

The presentation today by @ccameron-chromium was very informative regarding the "raw pixel values, do conversion yourself" aspect of WebGPU (and WebGL) compared to the "signal the colorspace for each command, the whole thing is color managed" aspect of 2D Canvas.

@ccameron-chromium
Copy link
Collaborator

Updating this with the planned API. WebGPU has the GPUSwapChainDescriptor dictionary currently

dictionary GPUSwapChainDescriptor {
    required GPUDevice device;
    required GPUTextureFormat format;
    GPUTextureUsageFlags usage = 0x10;  // GPUTextureUsage.RENDER_ATTACHMENT
    GPUCanvasCompositingAlphaMode compositingAlphaMode = "opaque";
    GPUExtent3D size;
};

We would just add a PredefinedColorSpace to this.

@DamonPalovaara
Copy link

Has there been any updates on this?

@palemieux
Copy link
Contributor

I am working on a revised HDR Canvas strawman based on the feedback I have seen so far:

#95

The revised proposal focuses on adding baseline support for HDR imagery to Canvas, without precluding future optimizations and extensions. It does so by adding support for HLG and PQ color spaces (which are in widespread use) and 16-bit float samples (which are necessary for HDR).

I would think the same approach could apply to WebGPU (support for HLG and PQ color spaces and bitdepth > 8 bits).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants