[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D
On 04/09/2010, at 9:23 AM, Steve Baker wrote:
> That's fine - if you take PNG, and DO NOT gamma correct it - do a
> straightforward linear-space rendering and then gamma-correct the
> output, you get exactly the right answer. If you take a JPEG,
> reverse-gamma correct it, do a linear-space rendering and then
> gamma-correct the output, you get (barring roundoff issues) the right thing.
It seems to me that this issue is surfacing because browsers can select to apply gamma or not on a per image basis, but that ability is lost in WebGL due to multiple textures being used before the page is composited (with gamma correction).
I'm a little confused on a point though, as I thought it was the screen that is gamma corrected. There's a further complicating factor in that image scaling also involves gamma: http://www.4p8.com/eric.brasseur/gamma.html
So yes, Chris Marrin is right to point out that we need to talk about colour spaces rather than gamma. So I'm wondering if PNG vs JPEG colour spaces need to be on a per-texture basis, rather than glReadPixels after everything is done?
Eg, as Oliver said:
>> * The image includes a colour profile: then use that colour profile
>> * The image does not include a colour profile: then assume the image
>> is in sRGB
So to handle the per-texture issue, the transform would need to happen on draw rather than load? This sounds more correct, but also a hell of a lot more painful to actually implement (as well as the speed cost for a frequent operation).
I'm not saying anything useful here, just trying to get a picture (ha) of the issue. :)
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: