[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D
> On 03/09/2010 12:51, Steve Baker wrote:
>> 3) You are doing no lighting/blending/mipmapping/fog/etc and (for some
>> reason) you have also chosen not to do gamma correction at the end. In
>> that case and ONLY in that case, you should gamma-correct your textures
>> on input.
>> I maintain that very few WebGL applications will do (3).
> I think that the number of mobile devices which have "gamma correctors"
> is approaching 0 and, with the exception of doing the "correction" in a
> shader (which will screw up blending), control of any such "correctors"
> is outside OpenGL. So I suspect the number of applications doing 3 is
> quite large.
I strongly disagree with every single thing you just said!
1) EVERY mobile device that can support WebGL is capable of rendering the
final image to the screen (the "compositing" stage) by drawing a textured
quadrilateral using a gamma correcting shader. There is no need for
custom gamma-correcting CLUT hardware anymore...that's what we have
2) If you decided to put the gamma correction at the end of the shader(s)
that you use for rendering your 3D scene (which I most certainly don't
advocate!), it would indeed "screw up blending" - but less so than
applying the gamma to the textures before the shader runs. Gamma is a
non-linear effect and as such has to come after all of the linear effects
in the rendering pipeline.
3) You say that control of external gamma correctors is outside of OpenGL
- that's true but I didn't suggest that we have to use an external gamma
corrector. I specifically said that we can fix gamma using a shader in
the compositing stage.
4) You can't say how many applications are "doing 3" because there are (by
definition) no finished WebGL applications yet (because the specification
isn't 100% finished). The only applications that might fall into class
(3) are the ones that don't do ANY
or translucent-canvas compositing. Basically, every single 3D application
is class (1) or (2) - and preferably class (2) because (1) is an ugly
kludge. True class (3) applications should probably be using <canvas>
If the specification were to say that the compositor does gamma correction
by default (possibly with the option to turn that off for people who don't
want it for some very specific reason) then everyone should be happy and
we do things correctly without any nasty kludges hardwired into the
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: