[Bf-committers] OpenGL sRGB

[Jason Wilkins]

I was mainly referring to future shader code used to render Blender's UI,
but it is good to know that generated shaders are already gamma correct,
since that means users won't be surprised by gamma correct shaders :-)

If the shader pipeline is already end-to-end correct for gamma then the
only thing an sRGB framebuffer will help with is blending.

Ack, I always get confused when I think about this...  My assumption from
what you've said is that Blender's generated shaders produce sRGB colors as
output (meaning, they linearize the colors inside the shader, do the math,
then de-linearize before output the fragment).  If that is so, sRGB
framebuffer would have to be off, but the results will still be incorrect
if BLEND is enabled.

To be correct when blending we'd have the generated shaders output linear
RGB (when framebuffer_sRGB is present) and rely on framebuffer_sRGB to do
the gamma correction on output.

At least I think that is how it works.  I'm pretty sure there isn't a mode
that expects shaders to output sRGB and still get correct blending.




On Sun, Jul 28, 2013 at 4:32 AM, Alberto Torres <kungfoobar at gmail.com>wrote:

> Shader code already has functions for converting from/to sRGB, and it's in
> the generated shaders unless you disable sRGB both in textures and output
> color space. Maybe there's something wrong (e.g. is it converting
> sRGB->linear twice when reading a texture?). I make heavy use of the
> generated shaders in my engine, so I'll have to investigate this...
>
>
> 2013/7/28 Jason Wilkins <jason.a.wilkins at gmail.com>
>
> > OpenGL has the ability to automatically convert colors to the sRGB color
> > space when writing them to the framebuffer and also to read from textures
> > in a mode that treats the texture as being in sRGB space.
> >
> > Since I've converted GHOST to use GLEW in order to load WGL extensions I
> > was thinking it would be easy to go ahead and enable sRGB frame buffers
> as
> > an option (sRGB textures could come when I'm writing shaders later).
> >
> > sRGB can be selectively enabled/disabled as you draw.
> >
> > It should be off for drawing the UI and other elements whose colors were
> > selected by the user by looking at how they look on a computer monitor.
> >
> > It should only be on for elements like lit polygon models in the viewport
> > so that the lighting computations final result is gamma correct.
> >
> > But elements in the viewport like the grid floor, wireframes, outlines,
> > etc. should also not be rendered in sRGB because they are also UI
> elements.
> >
> > This leaves images like textures, previews, and render results.
> >
> > If an image is a jpg or something that has no color correction then can I
> > assume it is already in sRGB and doesn't need correction?
> >
> > And if an image does have color correction information I can assume that
> > Blender has already taken steps to make sure it is in sRGB?
> >
> > The leaves me thinking that the only place where Blender is not sRGB
> > correct is when drawing lit 3D models to the viewport.  So it should be
> > fairly easy to enable that.
> >
> > It also seems that when reading textures almost all of them will be in
> > sRGB, so special shader code will be needed to map them to linear inside
> of
> > shaders.  However, since it is so rare for shaders to be gamma correct,
> > this might actually result in strange looking results to people used to
> > incorrect lighting computations.
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>