[Bf-committers] OpenGL sRGB

Jason Wilkins jason.a.wilkins at gmail.com
Wed Jul 31 01:26:15 CEST 2013


Actually, I was wondering if we wanted to go so far as to add OCIO to the
game engine, or if just supporting sRGB would be good enough.


On Tue, Jul 30, 2013 at 2:39 AM, Sergey Sharybin <sergey.vfx at gmail.com>wrote:

> Not sure what do you men "for games"?
>
> If it's for game engine, think it'll be fine. But maybe someone from GE
> department would disagree tho :)
>
>
> On Mon, Jul 29, 2013 at 8:27 AM, Jason Wilkins <jason.a.wilkins at gmail.com
> >wrote:
>
> > 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
> > >
> > _______________________________________________
> > 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
>


More information about the Bf-committers mailing list