[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] gamma/color profile and sRGB



On Fri, Nov 21, 2014 at 12:19 AM, Florian Bösch <pyalot@gmail.com> wrote:
> On Thu, Nov 20, 2014 at 11:36 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> How would an API like this work in the browser? The browser's window
>> can be dragged from screen to screen, changing the answer this API
>> returns.
>
> You could have a canvas.addEventListener('gammaRamp', function(ramp){...})
> which triggers whenever the majority of the canvas finds itself on a
> different display.

OK, that might work.

>> The browser is supposed to transform colors specified in the sRGB
>> color space ( http://www.w3.org/TR/css3-color/ ) to the display's
>> color profile. In practice, only Safari and IE handle this correctly
>> today, and they rely on the OS's colorspace support to do so. There's
>> an ongoing effort in Chrome to handle multiple displays' color
>> profiles correctly, and to do so on all operating systems. Not sure
>> about work in this area in Firefox.
>
> There's two things to do actually.
>
> Make sure that no color space conversion is applied if the WebGL context
> returns plain values. This would make roll-your-own colorspace handling
> easier.

This should basically already be happening. In Chrome, at least, the
browser does nothing with the WebGL context's color values when
compositing them into the window.

> Make sure that the correct color space conversion is applied if the WebGL
> context does return in sRGB (for which we're currently lacking any
> mechanism)

Right. More prototypes of WebGL 2.0 are needed in order to experiment with this.

>> For WebGL 2.0 I think a new context creation attribute is needed to
>> let the application allocate an sRGB back buffer. The browser's
>> compositor would handle that differently when drawing it to the
>> screen. More guidance from experts in colorspace handling is needed.
>
>
> We've had the discussion on explicit drawing buffer creation a while ago (in
> a different context). Where it partained to attaching a context to different
> drawing buffers, which would be quite useful. Does the canvas CR2 spec
> handle this case by now?

Embarrassingly, not yet. The discussion's recently been reopened
though. https://wiki.whatwg.org/wiki/WorkerCanvas will be pushed
forward more in the coming weeks.

> Could we have an interface to explicitely create
> drawing buffers? It would sometimes be useful to be able to draw on
> different drawing buffers with different attributes (for testing and other
> things).

The alternative proposal https://wiki.whatwg.org/wiki/CanvasInWorkers
, which allowed more explicit creation of drawing buffers, didn't get
traction with Mozilla because of requirements from asm.js customers
that they be able to render from a worker thread without any
interference from the main thread. The WorkerCanvas proposal achieves
the same basic use cases with a slightly different API.

-Ken

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------