How about just supporting sRGB for games?
On Sun, Jul 28, 2013 at 9:29 PM, Sergey Sharybin <[email protected]>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 <[email protected] > >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 <[email protected] > > >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 < > > [email protected] > > > >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 < > [email protected] > > > > >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 > > > > > [email protected] > > > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > _______________________________________________ > > > > Bf-committers mailing list > > > > [email protected] > > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > > > > > > -- > > > With best regards, Sergey Sharybin > > > _______________________________________________ > > > 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 > > > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > 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
