CEGUI (Crazy Eddie's GUI) Forums

Here's a feature request: add support for gamma correction.

Problem: in this age and day, a lot of apps are creating their backbuffer as R8G8B8_UNORM_SRGB (or the equivalent in OGL) to use the hardware for final gamma correction, and all the render pipeline is in linear space. Unfortunately CEGUI doesn't take that into account, which means that all the images will appear too bright.

I got around this problem by creating a render target, rendering CEGUI into it, and then binding a pixel shader to do gamma correction manually once I blend the GUI on top of my main screen. Though this solves the gamma correction issues, it introduces some artifacts with transparent widgets, caused by the default color used to fill the RTT buffer ( in my case black, which means all blended widgets have a dark halo ).

I think this could be solved by adding a flag when loading images, which would indicate whether they should be gamma corrected or not. Is that something doable ?

I faintly remember having a similar issue back when i worked with these OpenGL features. I know I solved it with some rather rarely used feature of OpenGL core that was made for cases like mine. However I don't really understand what the issue in your case is. Correct me if anything of this is wrong:

- You got the glEnable(GL_FRAMEBUFFER_SRGB) flag on the whole time
- The CEGUI textures are all in non-SRGB mode
- The CEGUI textures are therefore not converted to linear space when sampled and therefore all CEGUI-colours in the FBO are nonlinear

Give me a helping hand, I forgot how the following works: How do you render your SRGB buffer onto the final FBO? Isnt there an additional step included? As far as I know you cant create the OpenGL context's FBO as an SRGB one. So do you blit it or something like that as the last step before buffer swap? I really don't remember the details here so the more info you give me the better.

Sorry if I wasn't clear, but I actually use DX11.

In DX11 you can create the Swap Chain ( ie. the back buffer itself, in terms of OGL concepts, the one you glSwapBuffer from ) as an sRGB buffer. It is not an intermediary FBO. The final destination buffer itself is already sRGB. As a result it gets displayed "as is" by your monitor.

It's better to think of it in these terms. Imagine that you create a simple "standard" OGL or DX11 app, that doesn't use gamma correction. Ie. what everybody does for quick tests or simple apps. If you render CEGUI in this app, it'll appear with the "expected" colors. For example, that's what CEED is doing.

Now, if you modify this app's code to set the back buffer / swap chain as sRGB, and if you don't factor this in CEGUI, everything will be too bright due to the implicit gamma convertion.

In terms of practical code, the most simple would be to make a simple app ( or to modify your browser sample init code ) in DX11. Find the piece of code that creates the Swap Chain. In my code it looks like this:



That 'dxgiDesc' structure contains the member 'dxgiDesc.BufferDesc.Format'. You're probably using DXGI_FORMAT_R8G8B8A8_UNORM. That's not gamma corrected. Replace it by DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, and see what happens by doing a side-by-side pic comparison.

Here's an article that should help a bit and that explains the concept of an sRGB back buffer:
http://www.codinglabs.net/article_gamma_vs_linear.aspx

Of course it's possible to keep the back buffer as default and do some render-to-texture stuff, but it's more expensive. That's why a lot of engines use a back buffer of this format ( UE4 does that too AFAIK ), and it's a big pain with CEGUI

Nyast wrote:Here's an article that should help a bit and that explains the concept of an sRGB back buffer:
http://www.codinglabs.net/article_gamma_vs_linear.aspx

I didn't ask for that. Having used it in various different related techniques already in my own OpenGL rendering engine, I am already well acquainted with how gamma correction works and what it does. What is in question here is how you would specifically solve the issues you are having considering what techniques are available through the graphics library. Specifically for the purpose of interpreting the texture data correctly.

Nyast wrote:Of course it's possible to keep the back buffer as default and do some render-to-texture stuff, but it's more expensive

It doesn't make sense why this would be the only way. Afaik there is at least in OpenGL a way to do this directly.


If i assume right, the original idea you had was for us to implement the option to have all D3D or OpenGL textures that are loaded by CEGUI to be interpreted as SRGB textures, is that correct?

Yeah I think so. The most efficient way to solve that IMO would be to add a global flag that would force the textures to be loaded as sRGB. Or it could be a per-imageset flag too, though I'm not sure if there would be any point in that.

It should be per-renderer or per-Imageset. I would make that dependent on the implementation of the Imageset. I don't know specifics of it right now.

If the SRGB way is the best way to do this then we also shouldnt think about other options and I do think this is the best way for both D3D AND OpenGL.

Do you want to make a Pull Request for this feature?
Currently I am absolutely swamped so there is no chance I am gonna implement this anytime soon but this would definitely be nice-to-have for the 1.0 Release. I could put it on my to-do list but if you offer to do a PR I can help you out with implementation. I am not sure how easy this change is, theoretically it should be easy but in reality it might not (do for example the ImageCodecs need to be changed or is the Texture creation entirely Renderer-independent?, if it is independent it should be easier, etc etc etc)

Sorry for getting back to you that late. I don't know when you plan to do your 1.0 release, but if that's not urgent, I could spare some time to do the implementation sometime by mid 2015.

I'm currently working on a video game project and we're planning to launch a Kickstarter by April, so I absolutely have no free time to before that

1.0 won't happen before April. I will probably start working on 1.0 around April, when my Master's degree should finally be finished and after 1.0 I will plan to also develop a game

If you wanna get back to this you really should. I encourage you. CEGUI will still be around then and so will we and your changes would definitely go into 1.0 Release.

Oh, also, if your game uses CEGUI, please make a thread in the project announcements. Maybe we can also arrange to create a news for you on the main page (we get a lot of page hits so it can only be beneficial for you)