[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The Newly Expanded Color Space Issue
On Wed, Sep 8, 2010 at 8:42 PM, Steve Baker <firstname.lastname@example.org> wrote:
> Chris Marrin wrote:
>> It's time to bring this issue to a conclusion. We can't make WebGL programs correct, and we can't tell authors that we will only accept mathematically correct WebGL programs. What we CAN do is to give authors sufficient tools (given the current constraints) to give them the flexibility to do what they want with WebGL. As Adrienne and I have pointed out the only things we can do are:
>> 1) Manipulate the color space of images being loaded with texImage2D. Choices are:
>> a) Convert all images to sRGB always
>> b) Convert all images to Linear always
>> c) Give a choice of which conversion to perform
>> (with all choices, we also need a way to turn off all conversion and get raw pixels into the engine)
>> 2) Manipulate the color space of the drawing buffer as it is composited with the page. Choices are:
>> a) Always convert the drawing buffer as if it is sRGB into the device color space used by the compositor
>> b) Always convert the drawing buffer as if it is Linear into the device color space used by the compositor
>> c) Give a choice of which conversion to perform
>> I can live with any combination of the above. Currently my first choice would be 1c and 2c, with the default being sRGB for both. Please don't criticize those choices as wrong, just make your own choice.
> 1c and 2c are indeed the obvious choices (there has to be a "do no
> conversions at all" option too)...that is what I've been saying since
> the very beginning...that is what I proposed in an earlier effort to
> wind this debate up. But I think you're still missing the point.
> The WebGL specification has to express the actual truth of what the
> hardware actually does. And that - beyond any shadow of doubt is that
> it is a linear color space engine. Chris has argued that any color
> space can be supported by appropriate shader code - but when questioned
> closely about how he'd actually do that...claims that he doesn't have
> the expertise to actually demonstrate that...OK, fine...if you don't
> have the expertise - then listen to those who do and stop making claims
> for what can and cannot be done in shader code.
Please. Don't pick on Chris because he didn't have time to educate
you on how gamma works. Go back and read my (correct) answers to your
questions, that you insisted were unanswerable.
> The undeniable truth is that the GPU hardware has built-in linear
> interpolators and blenders that you can't circumvent - and that you
> can't affect with code. That makes it a linear color space
> engine...period. We cannot lie to our specification readership about that.
> However, it is certainly possible to approximate some other useful color
> spaces - mildly abusing this linear arithmetic system by passing
> non-linear data through it. Sometimes this is a useful thing to
> do...but people deserve to choose this route with their eyes wide open.
> But we can't go around telling the programmers of the world that WebGL
> operates in sRGB color space. The only space it correctly operates in
> is linear...and contrary to Chris' claims, it does do this
> perfectly...within limits of arithmetic precision.
> We can (and certainly should) provide image loading features that
> convert sRGB->linear or linear->sRGB or raw->raw. We can (and
> arguably should) provide compositing code that converts linear->sRGB (to
> match the browser's model) or sRGB->sRGB or sRGB->linear or raw->raw.
> That gives the programmers and artists the ability to use the (strictly
> linear) engine that is the GPU in any way they see fit and to accept
> whatever approximations and errors come from that decision.
> But we must not lie to them...that's unconscionable.
> The best compromise solution - in my view is:
> * Honestly specify that the GPU is a linear color space device. NEVER
> LIE TO THE USERS!!!
> * Provide whatever input and output color space conversions are need to
> support that fact. Explain clearly what these do.
> * Explain that you might want to use the GPU for other color spaces
> (such as sRGB) and that although while WebGL can only operate as an
> approximation of a true sRGB engine, it is sometimes useful to accept
> those approximations.
> * Therefore, provide whatever input and output color space conversions
> are needed to support that practical use of the GPU.
> * Above all - allow the programmer to disable any and all conversions at
> every step of the way. Not all data pushed into or out of the GPU is
> imagery - or even graphics of any kind. There are plenty of other uses
> for a powerful linear computational engine that are not even graphics at
> The end result is no different from Chris' (1c) and (2c) options -
> except in how we document them. We must not pretend that the GPU is
> something that it's not.
> -- Steve
> 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:
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: