[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The Newly Expanded Color Space Issue
2010/9/7 Chris Marrin <firstname.lastname@example.org>:
> 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
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: