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

Re: [Public WebGL] The Newly Expanded Color Space Issue

On Sep 7, 2010, at 8:36 AM, Ilmari Heikkinen wrote:

> 2010/9/7 Chris Marrin <cmarrin@apple.com>:
>> In fact, I don't think there should be an option to convert images to linear space at all. The option should be to simply turn off any color space conversions (as we've been discussing all along). I believe this gives authors sufficient flexibility given our other constraints. An author can set the drawing buffer to linear to be able to do "correct" math. And images can be brought in without correction to allow the author to use any color space on the original source image. Because  of the lack of ability to define a drawing buffer with sufficient bits per component, this might result in banding. In that case an author could choose to work in sRGB color space. The math might not be right, or the shaders might have to be more complex. But the author might choose to do so to achieve the desired results.
> My reading of the problem is that it's sometimes desirable to convert
> images from one color space to another, especially to sRGB and to
> linear FP once the float texture extension is available. Images should
> be passed to WebGL as-is to avoid lossy conversions. The output of the
> WebGL app should be in the HTML document color space (sRGB?) to avoid
> lossy conversions at low bit depths when compositing the web page.
> So maybe one solution would be to have an iconv for color spaces and
> an example fragment shader to convert a linear FBO to the document
> color space (or if the proposed colorSpace : 'linear' uses a higher
> depth frame buffer for rendering, that'd work too).
> The image color space conversion apparatus should probably be outside
> WebGL, I imagine it would be useful for other image munging code as
> well.

Creating a JS library which did color space conversion would be pretty straightforward. You write the image to a 2D Canvas and then use pixel access to do the conversion. Since all images in the 2D Canvas are sRGB, you'd always know the source color space. This would be a lossy conversion, assuming you put the result back into an 8 bit-per-component image (which is what 2D Canvas uses).

The output of the WebGL Canvas would always be in the HTML device color space. The question is where it gets converted to that. If the WebGL canvas is kept in sRGB, then it gets treated like all other image assets in HTML. If it is linear, then it gets converted into sRGB so it is the same as all the other assets. In fact, it possible that an implementation could skip the linear to sRGB conversion and go straight to the device color space if it's different. I believe all these scenarios are possible if we add the 'colorSpace' flag to WebGLContextAttributes.


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: