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 <[email protected]>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 <[email protected]> > > > 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 > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
