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

Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D

On Sep 5, 2010, at 4:51 AM, stephen white wrote:

> On 05/09/2010, at 8:26 PM, Thatcher Ulrich wrote:
>> It seems to me there are two unresolved questions for WebGL 1.0
> I'm not sure that my point was understood, so I'll try again...
> When a browser composites an image onto the page, that image is the entire block of pixels. The browser can have simple rules because of that.
> When WebGL draws to its canvas, it is using a number of images within the block of pixels. Therefore the number of different images may have different colour spaces and/or gammas.
> The additional complexity is coming from multiple images used together, which is not a problem that simply displaying an image had to worry about.
> As far as I can work this out, Steve Baker's suggestion of an option to reverse-map back to a linear colour space is the only mathematically valid option.
> In practical terms, this would work out to a "WEBGL_MAP_TO_LINEAR" loading time option that doesn't do any work for linear PNGs but does fix up colour space JPGs.
> If the option isn't set, then the JPGs are not touched and it's up to the programmer to do what they think is best.

It's true that native OpenGL apps can make any decisions  they want about the color space of incoming images, the represented color space of the drawing buffer, and the conversions done to the drawing buffer on display. But we have to be well defined on all aspects of color space management. That doesn't mean we have to be "correct" (if there is such a thing). We just have to be consistent.

Given the text in the http://www.opengl.org/registry/specs/EXT/texture_sRGB.txt, it seems as  though (at least most recently) OpenGL is assuming today's images are coming in linear. I think that's a bad assumption since, as Ollie points out, WebKit assumes JPEG images without a color profile to be sRGB. But I'm ready to accept that the should break with the 2D Canvas' tradition of representing the canvas as sRGB and maintain the WebGL canvas as linear. 

I'd like to get the discussion more focused. We have to decide several things:

1) What color space is the WebGL canvas?

As I said, I agree that the drawing buffer should be considered to be linear. This implies that the drawing buffer will have to be color corrected when composited with the rest of the HTML page. This also implies that, when using a WebGL canvas as the source image for a 2D Canvas drawImage() operation, it has to be color corrected into sRGB space, since that's what 2D Canvas expects.

2) What is the default incoming color space of images as textures, and what are the options to change that?

I believe the choices are: unchanged (I will call that raw), linear and sRGB. I think we need to support raw and linear.If an when we support EXT_texture_sRGB, we will get the ability to support incoming sRGB images.

This decision really concerns me. WebKit considers images without a color profile to be sRGB, but OpenGL (by statements in the EXT_texture_sRGB spec) assumes images without a profile to be linear. Which assumption do we make? Do we color correct all incoming images into linear space (assuming they have all been color corrected into sRGB already)? Or do we bring in images without a color profile unchanged, and only correct images that have a defined color profile. If we do the former, we will have different visual results than the corresponding native OpenGL program. If we do the latter, we will get results that are inconsistent with the rest of the HTML page.

3) What is the color space of pixels coming out of the drawing buffer via toDataURL() and readPixels()?

For consistency, I think toDataURL() should be color corrected into sRGB. But it seems more reasonable to leave the results of readPixels() in the same linear color space of the drawing buffer. This would have to be clearly spelled out.


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: