Better UI support for sRGB textures.

TL;DR: We render the right thing now, please let's not change it (the status bar text might need some tweaking). There is no need for toggle.

My long standing option is that all non-float textures are sRGB.

RGB8 and friends really has to be sRGB, and there is not enough precision in 8-bit for linear space.
float/HDR textures on the other hand have so much precision they are always liner space.

When you work with 8-bit colours in computers, it pretty much always implies sRGB, whether it is stored on disk, in memory, or pixels in on screen buffer. Thus, just taking the 8-bit colour and rendering in the client as-is is always the right thing to do. There is no conversion needed for rendering RGB8.

On the other hand, HDR textures always need conversion from liner-space float to the sRGB-space 8-bit to be rendered on screen, and we also need the histogram to choose the range to represent.

So if things are so simple, why does the spec even mention sRGB? That is because doing arithmetic on sRGB values (blending, lighting, etc...) is generally not valid as it is in log-space! People often ignore that fact, as it still looks-kind-of-ok and it is faster not to convert (think of your average UI framework... do you really care?) . That is 99% of computer software. But people, who care, need to do arithmetic in liner-space, which means converting inputs to shaders from sRGB to linear, and then converting outputs from linear to sRGB.

Those two conversions (in and out) are pretty simple, but it is in fragment shared, and involves SFU instructions... so actually pretty costly. That is why the GPUs has dedicated logic to do this automatically in hardware (where property of the texture/sampler turns on/off the hardware input converter, and property on the framebuffer turns on/off the hardware output converter). You can obviously turn of the hardware converter, and do the conversion yourself in the shader - it is more costly, but equivalent. So all of the sRGB fluf in the spec is just a way to add some hardware assisted fast conversions in the shaders, it does not really affect how we should render textures/framebuffers on screen. 8-bits are always sRGB, simple.

Important sidenote on the api state control:

The output converter is controlled by glEnable(GL_FRAMEBUFFER_SRGB). That is pretty obvious. Yay.
There no such capability for the input converter. Instead it is controlled by extra state on the texture. In particular, if the texture is defined as GL_SRGB8, it will turn on the input converter in all places where it is used. If it is defined as plain GL_RGB8, the hardware converter is off, and you must do it yourself in the shader. So the "S" controls hardware state in shader, but it does not describe what the bytes mean. Both GL_SRGB8 and GL_RGB8 store sRGB-space values. It is a bit confusing. I read the design notes somewhere, basically, I think their thinking was "we need per-texture control of the input-converter, but to make the dedicated hardware lookup tables simple, the converter is allowed to be used only with the GL_RGB8 format, all other formats still need manual conversion in shader. How do we enforce that in the API? Well, if we just bolt-on the converter state into the format, by adding GL_SRGB8 format, then the API change is trivial, and the user can not, by definition, enable the converter in unsupported cases"

So what we render in texture view and framebuffer view is always clearly defined, and we currently do the right thing. Yay. The only question is, when you hover over a pixel, what do you show in the status bar? The 8-bit values are always sRGB regardless of any GL state or texture format. Simple. But what do you show? The #428042 raw-byte format is unambiguous, but should the printed floating point value be just the trivial (byte/255.0), or should it be the linear-space-converted floating point?

On one hand, if I have colour #0080FF, I would kind of expect to see approximately (0.0, 0.5, 1.0). Or I would expect to see exactly (0, 128, 255).
On the other hand, float/HDR textures will lack #HEX colour, and will have only liner-space float, so it would be more consistent to just say the float values in status bar are always liner-space (and maybe even include the text "Linear-space RGBA: " in the status bar, for clarity).
There is mixed approach where we show the intermediate value which will be loaded into shader after the optional fast hardware conversion. I am not big fan of this, as it means we would keep changing the colour space depending on state. We could add clarification (e.g. for GL_RGB8 format, show "#HEX, sRGB-space RGBA: (.... ,... ,... ,... )", and for GL_SRGB8 format show "#HEX, Linear-space RGBA: (.... ,... ,... ,... )"). And yes, it is kind of backwards: GL_RGB8 will result in sRGB value (non-converted) being loaded in the shader, and GL_SRGB8 will result in linear-space value being loaded in the shader (as the "SRGB" means "turn the input hardware convertor on"). Also what do you do in framebuffer view? Decide based on whether the output-converter is currently on? (GL_FRAMEBUFFER_SRGB) Or use the input-converter state of the underling texture? Icky.

My conclusion is:

We should not change how we render colours on screen. We do the right thing now, and any other behavior, will result in double gramma correction, in one way or other. (I am not sure if we correctly handle HDR now though)
I would go with always showing "Linear-space: " in the status bar for simplicity and constancy. Maybe something like "sRGBA: (0, 128, 255, 255) Linear: (0.0, 0.7, 1.0, 1.0)"

That was a bit longer comment then expected :-D

google / gapid

Better UI support for sRGB textures. #1055