[Bf-committers] OpenGL sRGB

[Jason Wilkins]

I'd limit my proposal to using the sRGB framebuffer conversion and blending
features in OpenGL to only handling elements that do not use any image data
at all.  For example, drawing the lit "solid" mode of the viewport.  On
common monitors this simple correction would be an improvement.

As for making the viewport fully aware of OCIO, I can imagine drawing the
viewport to a texture map and then drawing it to the screen as a quad
through a shader that does the color correction.

I think a distinction should be made between using textures as data and
visualizing textures as data.  If you are looking at a normal map I think
that of course you want to apply some kind of correction to it so that you
understand the data properly.  When using the data, of course you want to
use the raw numbers.




On Sun, Jul 28, 2013 at 4:41 PM, Sergey Sharybin <sergey.vfx at gmail.com>wrote:

> I don't consider using hardcoded OpenGL's sRGB conversion is the way to go.
> It's not gonna to know linear space primaries and view transform you're
> wanna to apply.
>
> The thing proposed here could kind of work for the current state of how we
> use OGL and shaders, but we really need to make viewport fulyl aware of our
> color management (which is handled by OCIO).
>
> The thing which could here is OCIO's GPU-side color space conversion, which
> you're wanna to use as texture sharders for diffuse and some other
> textures.
>
> As for data-based textures we do not want to apply any kind of color space
> conversion to them. Meaning heights and normals maps shall always be used
> unmodified.
>
>
> On Sun, Jul 28, 2013 at 9:44 AM, Jason Wilkins <jason.a.wilkins at gmail.com
> >wrote:
>
> > GL_ARB_framebuffer_sRGB is an extension that tells OpenGL that the values
> > in the framebuffer are sRGB (i.e., they are being displayed on a computer
> > monitor) and therefore should be automatically gamma corrected when read
> > and written, allowing a shader to assume linear values and for
> framebuffer
> > blending to work correctly.
> >
> > I'm all for making sure that values are linear before being loaded as
> > textures, although if the GL_SRGB format is available, sRGB textures
> could
> > be loaded directly without conversion.
> >
> > The purpose of the sRGB extensions (framebuffer and texture) seems to be
> to
> > make the entire pipeline able to assume linear color values and only
> doing
> > the correction at the end points.
> >
> >
> >
> > On Sun, Jul 28, 2013 at 5:53 AM, Antony Riakiotakis <kalast at gmail.com
> > >wrote:
> >
> > > There is always some confusion over this. The idea is that gamma
> > correction
> > > should be done on the final result only. That means that ideally we
> > should
> > > linearize all textures prior to sending them to GPU and only gamma
> > correct
> > > at the end of the pipeline. For instance a diffuse texture should be
> > > linearized before interacting with light in the shaders. The reason
> this
> > is
> > > not always done is limited precision, especially for byte images.
> > >
> > > There are exceptions. Data textures are not linearized before passing
> to
> > > the GPU but might be required to be gamma corrected for display (Bump
> > maps,
> > > for instance). It's a nice mess really. Troy Sobotka and Morten
> Mikkelsen
> > > could give you lots of hints here.
> > >
> > > There are some disadvantages here, mainly that we will be confined to
> > sRGB
> > > if we use OpenGL sRGB. But we really only need different spaces for
> > render
> > > results and image displays so this might be a non issue.
> > > _______________________________________________
> > > 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
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>