New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create window in the sRGB colorspace #175

Closed
NicolBolas opened this Issue Feb 20, 2012 · 29 comments

Comments

Projects
None yet
@NicolBolas

NicolBolas commented Feb 20, 2012

It is often useful to create windows that use the sRGB colorspace natively. This is vital for maintaining a linear colorspace through to the screen. The WGL/GLX_framebuffer_sRGB (http://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt) explains how to do this.

ContextSetting should have a boolean field for this.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Feb 21, 2012

Member

Is this really an important feature? Is the difference significant?

I have the feeling that you're the only one to care/know about this kind of feature here.

Member

LaurentGomila commented Feb 21, 2012

Is this really an important feature? Is the difference significant?

I have the feeling that you're the only one to care/know about this kind of feature here.

@NicolBolas

This comment has been minimized.

Show comment
Hide comment
@NicolBolas

NicolBolas Feb 21, 2012

If you need to ask about whether gamma-correction, the sRGB colorspace, and maintaining a linear color pipeline is important, then I humbly suggest that you need to learn more about graphics. Gamma correction and gamma correct texturing is not something that should be ignored, and tools should not make it easy to ignore them. Indeed, good tools should encourage you to use these important features.

Here are some links for you to educate yourself on how important this is for actually drawing what you intend to draw:

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

http://maddieman.wordpress.com/2009/06/23/gamma-correction-and-linear-colour-space-simplified/

http://www.arcsynthesis.org/gltut/Illumination/Tut12%20Monitors%20and%20Gamma.html

http://www.arcsynthesis.org/gltut/Texturing/Tutorial%2016.html

The last two are part of my graphics tutorial book.

NicolBolas commented Feb 21, 2012

If you need to ask about whether gamma-correction, the sRGB colorspace, and maintaining a linear color pipeline is important, then I humbly suggest that you need to learn more about graphics. Gamma correction and gamma correct texturing is not something that should be ignored, and tools should not make it easy to ignore them. Indeed, good tools should encourage you to use these important features.

Here are some links for you to educate yourself on how important this is for actually drawing what you intend to draw:

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

http://maddieman.wordpress.com/2009/06/23/gamma-correction-and-linear-colour-space-simplified/

http://www.arcsynthesis.org/gltut/Illumination/Tut12%20Monitors%20and%20Gamma.html

http://www.arcsynthesis.org/gltut/Texturing/Tutorial%2016.html

The last two are part of my graphics tutorial book.

@Groogy

This comment has been minimized.

Show comment
Hide comment
@Groogy

Groogy Feb 21, 2012

This is only supported on newer hardware. Also you can do this manually by writing in the end of your fragment shader:

void main()
{
        /* Code */
        gl_FragColor = pow( finalColor, 2.2 );
}

Clarification: The texture format is only available on newer hardware/drivers but writing it manually in shaders are of course supported. Xbox for instance doesn't support the texture format but developers still have gamma correction made for their games.

For instance rendering into sRGB textures are not supported until OpenGL 3.0 and even then it's still as an extension and not merged in to the OpenGL specification. So for SFML relying on it that is going to be based on OpenGL 2.0 is bad to say the least.

Groogy commented Feb 21, 2012

This is only supported on newer hardware. Also you can do this manually by writing in the end of your fragment shader:

void main()
{
        /* Code */
        gl_FragColor = pow( finalColor, 2.2 );
}

Clarification: The texture format is only available on newer hardware/drivers but writing it manually in shaders are of course supported. Xbox for instance doesn't support the texture format but developers still have gamma correction made for their games.

For instance rendering into sRGB textures are not supported until OpenGL 3.0 and even then it's still as an extension and not merged in to the OpenGL specification. So for SFML relying on it that is going to be based on OpenGL 2.0 is bad to say the least.

@NicolBolas

This comment has been minimized.

Show comment
Hide comment
@NicolBolas

NicolBolas Feb 21, 2012

Let's ignore the fact that your suggestion would mean that any blending happens in sRGB space instead of linear space (and therefore the blending would be wrong), as well as the fact that your code would also raise the alpha to a power. Let's just look at the simple practicalities of the suggestion.

How much does pow(finalColor, 2.2); cost in performance? I don't know off the top of my head, but I do know that sRGB conversion is free. So I'm guessing the power function is more expensive. Why waste performance?

We're not talking about something that's difficult to implement here; this isn't a massive implementation burden. We're talking about adding a parameter to ContextSettings and adding another pixel format setting internally when creating a context. That's all. It might take 15 minutes, 45 on the outside.

And yes, there is hardware that doesn't support it. But "newer hardware/drivers" means "any GPU made in the last 6 years." Even Intel's HD stuff supports sRGB pixel formats, and they barely support OpenGL at all. Yes, not every possible platform can implement it. But that doesn't mean that one should be deprived of it where available.

NicolBolas commented Feb 21, 2012

Let's ignore the fact that your suggestion would mean that any blending happens in sRGB space instead of linear space (and therefore the blending would be wrong), as well as the fact that your code would also raise the alpha to a power. Let's just look at the simple practicalities of the suggestion.

How much does pow(finalColor, 2.2); cost in performance? I don't know off the top of my head, but I do know that sRGB conversion is free. So I'm guessing the power function is more expensive. Why waste performance?

We're not talking about something that's difficult to implement here; this isn't a massive implementation burden. We're talking about adding a parameter to ContextSettings and adding another pixel format setting internally when creating a context. That's all. It might take 15 minutes, 45 on the outside.

And yes, there is hardware that doesn't support it. But "newer hardware/drivers" means "any GPU made in the last 6 years." Even Intel's HD stuff supports sRGB pixel formats, and they barely support OpenGL at all. Yes, not every possible platform can implement it. But that doesn't mean that one should be deprived of it where available.

@Groogy

This comment has been minimized.

Show comment
Hide comment
@Groogy

Groogy Feb 21, 2012

Dude if you're taking a little example I gave you explain how to achieve it and dissect it like if it were supposed to be a 100% accurate then it's going to be impossible to discuss with you.

No this is not difficult to implement. And that is not the issue at hand. The issue is not all hardware supports it. And the OpenGL version SFML will mainly run on does not support it. There will be more problems in using this and having it implemented than you expect.

Groogy commented Feb 21, 2012

Dude if you're taking a little example I gave you explain how to achieve it and dissect it like if it were supposed to be a 100% accurate then it's going to be impossible to discuss with you.

No this is not difficult to implement. And that is not the issue at hand. The issue is not all hardware supports it. And the OpenGL version SFML will mainly run on does not support it. There will be more problems in using this and having it implemented than you expect.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Feb 21, 2012

Member

It is an important issue, you get a point (and thanks for the links).

But you'll still be the only one to care about it. Most people using SFML are beginners, or write 2D games. There are very few (if not none) who develop a 3D engine with complex lighting/HDRL/... using SFML to create their OpenGL contexts.

And I don't want to add a feature for a single user, even if it takes me 5 minutes to implement. There are so many important things to do before.

Member

LaurentGomila commented Feb 21, 2012

It is an important issue, you get a point (and thanks for the links).

But you'll still be the only one to care about it. Most people using SFML are beginners, or write 2D games. There are very few (if not none) who develop a 3D engine with complex lighting/HDRL/... using SFML to create their OpenGL contexts.

And I don't want to add a feature for a single user, even if it takes me 5 minutes to implement. There are so many important things to do before.

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Feb 21, 2012

Actually, two people care about it. It would be nice if you could provide more access to things like the context settings so people who know what they're doing can implement these things themselves rather than asking you to change SFML.

retep998 commented Feb 21, 2012

Actually, two people care about it. It would be nice if you could provide more access to things like the context settings so people who know what they're doing can implement these things themselves rather than asking you to change SFML.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 23, 2012

I'm not very knowledgeable on this, but wouldn't it be better to just allow users to manage graphics contexts on their own? That way, they could create an sRGB context and pass it to sf::Window, and then, you cover all cases.

ghost commented Feb 23, 2012

I'm not very knowledgeable on this, but wouldn't it be better to just allow users to manage graphics contexts on their own? That way, they could create an sRGB context and pass it to sf::Window, and then, you cover all cases.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Feb 23, 2012

Member

Context creation is complex, highly platform specific, and cannot easily be done outside SFML.

Member

LaurentGomila commented Feb 23, 2012

Context creation is complex, highly platform specific, and cannot easily be done outside SFML.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 23, 2012

So is window creation, but you can pass custom window handlers to SFML, too.

ghost commented Feb 23, 2012

So is window creation, but you can pass custom window handlers to SFML, too.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Feb 23, 2012

Member

So is window creation, but you can pass custom window handlers to SFML, too

The purpose is to allow integrating SFML into other GUI libraries. Not to create your own window from scratch with OS-specific code.

Member

LaurentGomila commented Feb 23, 2012

So is window creation, but you can pass custom window handlers to SFML, too

The purpose is to allow integrating SFML into other GUI libraries. Not to create your own window from scratch with OS-specific code.

@NicolBolas

This comment has been minimized.

Show comment
Hide comment
@NicolBolas

NicolBolas Feb 23, 2012

To be fair RetroX, any user who wanted to write and maintain their own context creation code (which also means writing and maintaining Window creation), probably doesn't want to use SFML.

Indeed, the idea with this was for me to basically use SFML as a means to do sound, input, and manage window/GL context creation, while completely ignoring all of SFML's actual rendering routines. I do that with Allegro 5 now, which is an API that I like. But I was hoping to be able to trade it in for a nicer, more C++-ish API. But sRGB support isn't optional for me, so I guess I'll skip SFML and see if I can get the Allegro developers to add sRGB support.

Oh well.

NicolBolas commented Feb 23, 2012

To be fair RetroX, any user who wanted to write and maintain their own context creation code (which also means writing and maintaining Window creation), probably doesn't want to use SFML.

Indeed, the idea with this was for me to basically use SFML as a means to do sound, input, and manage window/GL context creation, while completely ignoring all of SFML's actual rendering routines. I do that with Allegro 5 now, which is an API that I like. But I was hoping to be able to trade it in for a nicer, more C++-ish API. But sRGB support isn't optional for me, so I guess I'll skip SFML and see if I can get the Allegro developers to add sRGB support.

Oh well.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 24, 2012

Eh, good point. :/

ghost commented Feb 24, 2012

Eh, good point. :/

@bananu7

This comment has been minimized.

Show comment
Hide comment
@bananu7

bananu7 Apr 2, 2013

Is this ever going to happen? SFML is a nice library, and limiting it to toy applications because something as simple as sRGB context creation couldn't be added seems like an awful waste for me.

bananu7 commented Apr 2, 2013

Is this ever going to happen? SFML is a nice library, and limiting it to toy applications because something as simple as sRGB context creation couldn't be added seems like an awful waste for me.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Apr 2, 2013

Member

To be honest, I don't know. There are many other important things to do, and there are still only 3 users interested in this feature. So even if it ever happens, don't expect it too soon.

Member

LaurentGomila commented Apr 2, 2013

To be honest, I don't know. There are many other important things to do, and there are still only 3 users interested in this feature. So even if it ever happens, don't expect it too soon.

@Niriel

This comment has been minimized.

Show comment
Hide comment
@Niriel

Niriel May 8, 2013

I discovered SFML twenty minutes ago while looking for an alternative to SDL that would let me create an sRGB context. Too bad.

Niriel commented May 8, 2013

I discovered SFML twenty minutes ago while looking for an alternative to SDL that would let me create an sRGB context. Too bad.

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj May 8, 2013

Such is life, can't please everyone all the time.

vonj commented May 8, 2013

Such is life, can't please everyone all the time.

@corngood

This comment has been minimized.

Show comment
Hide comment
@corngood

corngood Nov 23, 2013

On GLX I was able to glEnable(FRAMEBUFFER_SRGB) after context creation and it worked.

GLX_FRAMEBUFFER_SRGB_CAPABLE should probably be preferred when choosing a visual, but I doubt needs to be exposed through ContextSettings.

Personally I think SRGB framebuffer and sRGB textures (where appropriate) should be enabled by default. This is not a 2D vs. 3D thing. It's just as important for antialiasing vector graphics as it is for physically correct lighting. There are still compatibility concerns, but only with mobile devices, and they are evaporating quickly.

You also mentioned beginners, but that might be as good reason as any to make gamma correction the default, so they don't fall into the same bad habits that plagued computer graphics for so long.

TL;DR = try glEnable(GL_FRAMEBUFFER_SRGB)

corngood commented Nov 23, 2013

On GLX I was able to glEnable(FRAMEBUFFER_SRGB) after context creation and it worked.

GLX_FRAMEBUFFER_SRGB_CAPABLE should probably be preferred when choosing a visual, but I doubt needs to be exposed through ContextSettings.

Personally I think SRGB framebuffer and sRGB textures (where appropriate) should be enabled by default. This is not a 2D vs. 3D thing. It's just as important for antialiasing vector graphics as it is for physically correct lighting. There are still compatibility concerns, but only with mobile devices, and they are evaporating quickly.

You also mentioned beginners, but that might be as good reason as any to make gamma correction the default, so they don't fall into the same bad habits that plagued computer graphics for so long.

TL;DR = try glEnable(GL_FRAMEBUFFER_SRGB)

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Feb 26, 2015

Member

Just out of interest, since I might pick this up at some point: Does OS X support sRGB framebuffers? I know OS X supports the OpenGL extension, but the pixel format documentation doesn't provide any hints as to how an sRGB framebuffer would be created.

@mantognini do you have any ideas?

Member

binary1248 commented Feb 26, 2015

Just out of interest, since I might pick this up at some point: Does OS X support sRGB framebuffers? I know OS X supports the OpenGL extension, but the pixel format documentation doesn't provide any hints as to how an sRGB framebuffer would be created.

@mantognini do you have any ideas?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Feb 26, 2015

Member

I haven't found a clear answer but I think it is supported.

However, using OpenGL Extensions Viewer, with a Compatibility profile on a NVIDIA or Intel card, I could find those extensions (some might be aliased):

https://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt
https://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt
https://www.opengl.org/registry/specs/EXT/texture_sRGB.txt
https://www.opengl.org/registry/specs/EXT/texture_sRGB_decode.txt

Does it help you in some way?

Member

mantognini commented Feb 26, 2015

I haven't found a clear answer but I think it is supported.

However, using OpenGL Extensions Viewer, with a Compatibility profile on a NVIDIA or Intel card, I could find those extensions (some might be aliased):

https://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt
https://www.opengl.org/registry/specs/EXT/framebuffer_sRGB.txt
https://www.opengl.org/registry/specs/EXT/texture_sRGB.txt
https://www.opengl.org/registry/specs/EXT/texture_sRGB_decode.txt

Does it help you in some way?

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Feb 26, 2015

Member

Like I said... I know those extensions are supported. What I want to know is whether I can select a pixel format that provides me with an sRGB framebuffer through the OS X API. If you look in the specification for ARB_framebuffer_sRGB, you will find the new tokens GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB and WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB. These can be used when specifying a pixel format using GLX (Unix) and Wgl (Windows). There are no tokens for OS X, because... well... OS X context management isn't described in any ARB specifications.

OS X describes its pixel formats through an NSOpenGLPixelFormat object, and its API is maintained by Apple. I've (briefly) read through the documentation and they don't mention sRGB support anywhere.

It could very well be that even in 2015, Apple systems still don't support sRGB OpenGL framebuffers, but if you ask me it is hard to believe. Maybe they do it automatically? I've read that in other areas (not related to OpenGL), Apple has given some thought to supporting sRGB in some way so it seems strange they didn't do it here as well. I was hoping you had come across some OS X OpenGL documentation I have not yet seen regarding this.

Member

binary1248 commented Feb 26, 2015

Like I said... I know those extensions are supported. What I want to know is whether I can select a pixel format that provides me with an sRGB framebuffer through the OS X API. If you look in the specification for ARB_framebuffer_sRGB, you will find the new tokens GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB and WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB. These can be used when specifying a pixel format using GLX (Unix) and Wgl (Windows). There are no tokens for OS X, because... well... OS X context management isn't described in any ARB specifications.

OS X describes its pixel formats through an NSOpenGLPixelFormat object, and its API is maintained by Apple. I've (briefly) read through the documentation and they don't mention sRGB support anywhere.

It could very well be that even in 2015, Apple systems still don't support sRGB OpenGL framebuffers, but if you ask me it is hard to believe. Maybe they do it automatically? I've read that in other areas (not related to OpenGL), Apple has given some thought to supporting sRGB in some way so it seems strange they didn't do it here as well. I was hoping you had come across some OS X OpenGL documentation I have not yet seen regarding this.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Feb 26, 2015

Member

Unfortunately no, I've never seen sRGB in the document I've read.

But maybe other libs such as sdl or glfw do implement that...

Member

mantognini commented Feb 26, 2015

Unfortunately no, I've never seen sRGB in the document I've read.

But maybe other libs such as sdl or glfw do implement that...

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Feb 26, 2015

Member

It's always nice when you learn something new. 😁

I still find it strange though, that I couldn't find any official documentation/information from Apple.

Member

binary1248 commented Feb 26, 2015

It's always nice when you learn something new. 😁

I still find it strange though, that I couldn't find any official documentation/information from Apple.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Feb 26, 2015

Member

Why am I not even surprised that it was not documented? 😒

Member

mantognini commented Feb 26, 2015

Why am I not even surprised that it was not documented? 😒

@elliotpotts

This comment has been minimized.

Show comment
Hide comment
@elliotpotts

elliotpotts Mar 6, 2015

Any progress on this issue? sRGB is also holding me back from using SFML.

elliotpotts commented Mar 6, 2015

Any progress on this issue? sRGB is also holding me back from using SFML.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Mar 6, 2015

Member

I'll probably look into this and the other OpenGL related stuff after gl_dev gets merged. Shouldn't be too long.

Member

binary1248 commented Mar 6, 2015

I'll probably look into this and the other OpenGL related stuff after gl_dev gets merged. Shouldn't be too long.

@binary1248 binary1248 modified the milestone: 2.4 Mar 31, 2015

@binary1248 binary1248 self-assigned this Mar 31, 2015

@dezzik

This comment has been minimized.

Show comment
Hide comment
@dezzik

dezzik Sep 17, 2015

Any news? Would be a nice feature to have.

dezzik commented Sep 17, 2015

Any news? Would be a nice feature to have.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Sep 17, 2015

Member

Work is scheduled to begin after pending pull requests affecting the same files have been merged.

Member

binary1248 commented Sep 17, 2015

Work is scheduled to begin after pending pull requests affecting the same files have been merged.

@binary1248 binary1248 added s:accepted and removed s:undecided labels Sep 27, 2015

binary1248 added a commit that referenced this issue Oct 1, 2015

binary1248 added a commit that referenced this issue Oct 2, 2015

binary1248 added a commit that referenced this issue Feb 21, 2016

binary1248 added a commit that referenced this issue Feb 21, 2016

eXpl0it3r added a commit that referenced this issue Mar 10, 2016

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Mar 11, 2016

Member

Merged in e00d160

Member

eXpl0it3r commented Mar 11, 2016

Merged in e00d160

@eXpl0it3r eXpl0it3r closed this Mar 11, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment