[Bf-committers] OpenGL sRGB

[Jason Wilkins]

How about just supporting sRGB for games?


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

> I don't think you could do solid view with OpenGL's sRGB conversion even --
> ideally you still need to apply render part of color management for diffuse
> colors used for solid viewport as well.
>
> Generally speaking, i'm not sure it worth spending time on zapping c-side
> color space conversions in favor of using opengl's one just to change all
> the stuff again later.
>
>
> On Sun, Jul 28, 2013 at 4:01 PM, Jason Wilkins <jason.a.wilkins at gmail.com
> >wrote:
>
> > 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
> > >
> > _______________________________________________
> > 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
>