Gamma correctness with VSG

[AnyOldName3]

There are several problems with colour management in the VSG and ancillary projects, and so I thought it would be sensible to have a thread about it.

Basic background

The numbers you see representing a colour on a computer usually don't directly represent the number of photons that come out of the monitor to make that colour. Originally, CRT screens were built so that increasing the signal voltage had a (as close as was feasible) perceptually uniform effect, but human vision isn't linearly sensitive to brightness. Early computers mapped the numbers for colours directly to voltage in the cable to the screen, and then when things turned digital, screens mapped the numbers to the brightness a CRT would give for those numbers. If you're trying to do lighting for a 3D scene to present as an image, you therefore need to know what the screen's going to do with the numbers it's given, and the colour space that tells you this for a typical screen is called sRGB. The maths can be approximated pretty closely with $C_{linear} = {C_{sRGB}}^{\frac{1}{2.2}}$. If you ignore this, you get problems when adding light from different sources together $(C_1 + C_2)^{\frac{1}{2.2}} \neq {C_1}^{\frac{1}{2.2}} + {C_2}^{\frac{1}{2.2}}$ or attenuating light with distance $a\left(C^{\frac{1}{2.2}}\right) \neq (aC)^{\frac{1}{2.2}}$, and if you mix things up and only sometimes do the conversion, or do it when it doesn't need to happen, colours end up brighter or darker than they should.

Some history

Around the early 90s, it was typical for realtime graphics to totally ignore gamma correctness, as what you could do on a contemporary machine would never leave it as the most noticeable problem, but by the end of the nineties, there needed to be extra tricks to get away with ignoring it. A common one was giving point lights linear attenuation instead of quadratic attenuation like they do in real life, as $\left(d^{-2}C\right)^{\frac{1}{2.2}} = d^{\frac{-1}{1.1}}\left(C\right)^{\frac{1}{2.2}} \approx d^{-1}\left(C^{\frac{1}{2.2}}\right)$.

Eventually, GPUs started getting built-in support for sRGB conversions, and you could enable GL_FRAMEBUFFER_SRGB to have the fragment colour automatically converted before being written to the framebuffer with correct blending, and use sRGB variants of texture formats which would convert the colours from sRGB to linear when they were accessed (again, with correct filtering). You could then usually get all the convenience of ignoring gamma correctness with all the correctness.

More recently, things have got more complicated, first with post-process shader effects which may or may not want to consume linear colour, then with tonemapping (sometimes an image will look better if you do the colour space correction incorrectly intentionally, as it can preserve details that would be lost due to a screen's inability to be perfectly dark or ludicrously bright or show small brightness differences which a human can see), and most recently with the wide availability of HDR monitors with non-sRGB preferred colour spaces.

Out of the box, OpenSceneGraph didn't do much about this - you could manually enable GL_FRAMEBUFFER_SRGB, and visit any loaded textures to switch them to the sRGB variant of their previous format, but the image loaders loaded things as the non-sRGB versions.

VulkanSceneGraph does more, e.g. some of the loaders have options controlling whether images are assumed to be sRGB or not, and the built-in PBR shader does some colour space conversions. However, it's not perfect.

Current problems

This list might not be exhaustive, but it's what I've noticed so far.

• The PBR shader does some sRGB conversions, whereas the Phong shader does none. In principle, this should be orthogonal to the lighting method, as both should look better with correct gamma, and widespread use of correct gamma predated widespread use of physically-based shading, so it's not like it's normal to make this distinction. When using osg2vsg, I suppose the Phong shader will usually end up used, so it might end up having to deal with scenes which look wrong with correct gamma (e.g. because lights use linear instead of quadratic attenuation), so maybe there should be a way to opt out of gamma correction, but using the Phong shader shouldn't be it.
• The PBR shader does conversions of texture colours instead of letting the sampling hardware do it. When interpolating between different texels, it makes a difference if the texture's already been linearised, and leaving it up to the sampling hardware means the format can be set on the texture, avoiding the need to switch pipelines when using mixed data.
• Textures can already be set to have sRGB formats, and that means the conversion will happen twice and the colours will end up too bright if the shader's doing it a second time.
• The PBR shader's converting at the end. This means that:
  • post-process effects that need to consume linear colour will either be wrong, or need to convert back - if the shader didn't do it, you could just mark the framebuffer image format as sRGB or not to toggle the conversion.
  • blending will be incorrect.
  • HDR support will be harder as you can't just use the Vulkan extension feature that does an automatic conversion to whichever colour space the monitor uses.
• Loaded material and vertex colours are used as-is. Some formats are specified as always using a particular format (e.g. glTF says which values should be linear and which should be sRGB), some defacto use sRGB due to being unmodified for decades, and some should be one format or the other, but have files in the wild with both, either due to off-spec editors, or meshes being made specifically for a particular renderer which did things its own way. AssImp deals with this problem by ignoring it, meaning sometimes it'll give you linear colour and sometimes sRGB, so something needs to handle it in vsgXchange, e.g. querying what was just loaded and having a map from format to whether or not conversion to linear needs to happen (which would default to whatever was typical, but would probably benefit from being overridable with an option), and then doing the conversion if it says to.
• Images from the stbi loader are assumed to be non-sRGB, despite almost certainly being sRGB if they're colour data (and for some of the formats, they've even got a way to tell you their colour space, although I'm not sure what can be done about this as stbi doesn't tell us). This is complicated further by things like normal maps, which look like colour data, but aren't, so don't want a conversion from sRGB before they're used.
• Images from the DDS loader with the old-style FOURCC formats instead of the newer DXGI enum are assumed (within tinydds) to be non-sRGB, when they almost certainly are sRGB (again, unless they're for something like a normal map).

[timoore]

Nice writeup about the issues.

Current problems

This list might not be exhaustive, but it's what I've noticed so far.

• The PBR shader does some sRGB conversions, whereas the Phong shader does none. In principle, this should be orthogonal to the lighting method, as both should look better with correct gamma, and widespread use of correct gamma predated widespread use of physically-based shading, so it's not like it's normal to make this distinction. When using osg2vsg, I suppose the Phong shader will usually end up used, so it might end up having to deal with scenes which look wrong with correct gamma (e.g. because lights use linear instead of quadratic attenuation), so maybe there should be a way to opt out of gamma correction, but using the Phong shader shouldn't be it.

• The PBR shader does conversions of texture colours instead of letting the sampling hardware do it. When interpolating between different texels, it makes a difference if the texture's already been linearised, and leaving it up to the sampling hardware means the format can be set on the texture, avoiding the need to switch pipelines when using mixed data.

• Textures can already be set to have sRGB formats, and that means the conversion will happen twice and the colours will end up too bright if the shader's doing it a second time.

• The PBR shader's converting at the end. This means that:

  • post-process effects that need to consume linear colour will either be wrong, or need to convert back - if the shader didn't do it, you could just mark the framebuffer image format as sRGB or not to toggle the conversion.
  • blending will be incorrect.
  • HDR support will be harder as you can't just use the Vulkan extension feature that does an automatic conversion to whichever colour space the monitor uses.

For reference, here's what vsgCs does to try to approach gamma correctness:

• A swapchain format of VK_FORMAT_B8G8R8A8_SRGB, VK_COLOR_SPACE_SRGB_NONLINEAR_KHR is requested. This means that linear colors written to the attachment will eventually be converted to SRGB on output;
• vsgCs' glTF loader stores all image textures in SRGB formats;
• The shaders don't do any gamma conversion.

I think this is the goal to shoot for in VSG.

[AnyOldName3]

I've opened #1302, vsg-dev/vsgXchange#204 and vsg-dev/vsgXchange#204, which fix some of the problems and lay some groundwork for fixing some of the others.

They include:

• A more sensible default swapchain format.
• Shaders are consistent with their gamma correction.
• Shaders write their results in linear and rely on the automatic conversion from the more sensible default swapchain format.
• AssImp-based formats should load with their colours in the right colour space.

They notably don't include any changes CPU-side to textures as it's still more obvious which textures are probably-sRGB versus probably-linear when in the shader and about to use them, but I can look into that next.

[AnyOldName3]

I've still not thought of a great solution for osg2vsg, as the OSG more or less ignored gamma correctness as a concept, so lots of things won't look identical unless things are done incorrectly on purpose, but lots of things will look better. It's generally just scenes where things like object colours and light positions were fine-tuned to look a certain way, or setups with non-gamma-correctness mitigations (e.g. point lights with physically implausible linear attenuation) that won't look better. I don't know to what extent the priority of osg2vsg is faithfulness versus just being a way to quick-start VSG-based projects - I know it mostly started as the latter, but that's not necessarily its long-term goal. I also don't know the prevalence of OSG-based data that's been carefully crafted to look perfect but the route taken wasn't to make life easier by making a given app gamma-correct.

[AnyOldName3]

With the batch of PRs I've collectively labelled Phase One, I think I've made a big dent in the problem. The biggest remaining problems are:

• Shaders are still doing the sRGB conversions when loading images. Instead, we should be using sRGB image formats for the relevant textures so the sampling hardware does it before filtering. We need to figure out how to judge which textures to do this for so it doesn't happen for normal maps, images which are already linear (e.g. using the VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 format, but this example is a trivial case as we can tell from the image format), or users who are explicitly opting out for whatever reason.
• Deciding what to do about .vsgt and .vsgb files.
• Deciding what, if any, handling needs to happen in osg2vsg.

[AnyOldName3]

@robertosfield and I had a discussion about this problem, and one of the things that came out of that was that it would be a good idea to have visitors that can convert the colour spaces of vertex colours and materials in the scene graph, and switch image textures (but not data textures) between the SRGB and UNORM formats. However, I've been exploring how to do that, and everything I've come up with is a nasty mix of overengineered, backwards-incompatible and incapable of dealing with data that will already exist in the wild.

If the requirement is only that the VSG's built-in shadersets are supported, it's relatively straightforward to find descriptor buffers and then inspect everything they contain for PBR and Phong materials, as they both have RTTI that identifies them, and contain the actual values we'd want to modify, and it's a similar story for vsg::Text. This is already generally not brilliant, as it wouldn't work with osg2vsg's shaders or anything that users come up with, and will need dedicated subclasses for different situations.

However, there's an even bigger problem with vertex colours. Currently, there's nothing that remains in the scenegraph that identifies what any vertex attributes mean beyond their format (which normally just says whether they're floats or ints and whether they're scalars of vectors) and binding number. Parts of the VSG like the graphics pipeline configurator do know the attribute names at the same time as having access to the buffers, so do in principle have the ability to label new fields in classes like VertexInputState if we were to add them, but the graphics pipeline configurator isn't necessarily involved when state is set up (and lots of the examples don't use it), so relying on it alone would still mean scenegraphs in the wild wouldn't be compatible with a visitor even if we added new fields to a few classes unless we made setting the extra fields mandatory. It seems likely that those fields would end up set incorrectly if it was left up to users and the only symptom was a visitor that most people wouldn't use not working.

There's an existing annoyance that a .vsgt or .vsgb file will end up embedding the standard shadersets in a way where you can't tell that that's what's been embedded, so when loading them with a different version of the VSG where those shaders have changed, there's not a practical way to reliably update the shaders, and doing something about that might make it easier to identify which vertex attributes do what (e.g. keeping the ShaderSet instance around rather than just applying it and letting it identify whether it's one of the built-in ones). Even that approach to identifying the vertex attributes isn't great as while we could check if one's called vsg_Color, like the standard Phong, flat, and PBR shaders want, other shaders won't use the same name, and many of the ones in the examples don't.

If users have to provide their own implementations of the colour space conversion visitor(s), it would seemingly defeat the purpose of providing any.

So after thinking about this for quite a long time, I still think something roughly along the lines of my original approach, where the loaders (which necessarily need to know what they're loading, except for the .vsgt/.vsgb one, which are loading an arbitrary scenegraph rather than semantically converting between a format and a scenegraph) are responsible for recognising what is and isn't a colour, and performing the conversion the user wants, would be best. I'm now leaning towards it being some kind of functor rather than an enum, so there's more power for the user to add more colour spaces without waiting for them to be upstreamed, though.

[AnyOldName3]

One of the things I've been working on is an example which updates the example models that come with vsgExamples, as:

• They'd look bad if they weren't updated.
• It should serve as a good example of what users might need to do with their own data, and some ways they might do it.
• None of the models have needed quite the same processing as each other, so it's a good illustration of why coming up with something universal isn't viable.

I've noticed a couple of things, though:

• skybox.vsgt looks more sky-coloured if I don't do anything to adapt it to make it look how it used to, so I'm pretty sure it's been linear all along and has been erroneously presented as sRGB for years.
• even when everything possible is done to make the colours look the same as before, there are still differences.

A good example of the difference is the teapot:

Before (incorrect gamma)

After (correct gamma)

The hue varies across the model in both images, but it's a much smaller range in the gamma-correct version. That's a good thing, and makes sense - when going through a non-linear function, the different brightnesses of the different colour channels are affected differently, so the ratio of photons of different wavelengths gets altered, and without correct gamma, different parts of the yellow teapot pick up a red or green tinge.

Also, the mid tones are more realistic, so that's a nice bonus, but that's a really obvious consequence of being gamma-correct as all it does is change mid tones.

[robertosfield]

The 3D models that we have in vsgExamples/data really don't show off Vulkan/VSG capabilities, no PBR, no animation and they don't all integrate with all the examples well.

So I'd be inclined to find replacements that provide a better illustration of what the VSG can do out of the box. Open to suggestions on this.

[AnyOldName3]

The standard glTF samples would be pretty good at showing off a lot of what can be done, but there are a lot of them these days and they're only adding more. Recommending them as sample models and linking to them would probably be a step in a good direction even if it's impractical to provide them all in a subdirectory.

Most of the incompatibilities with the existing samples seems to be because they have embedded shaders and attribute/descriptor bindings that don't match any of the built-in shader sets, so potentially adding a way for .vsgt files to say use the default PBR shader set (probably with some handling to fixup files using an old version when the interface changes) and switching the existing examples to that would work. The map examples don't embed shaders, and don't seem break as often in my experience.

[robertosfield]

I'm think of perhaps one or two glTF samples. I haven't recently spent the time thinking about the needs of vsgExamples/vsgTutorial but as we start looking at making a VSG-1.2 stable release I think it would make sense to look at what we can refine a bit with vsgExamples/vsgTutorials.

[AnyOldName3]

Just so it's noted down somewhere, I've seen a couple of problems with glTF sample assets today when checking the colours are handled properly:

• we're possibly drawing normal maps inside out. This is probably the classic DX-versus-GL-convention problem. I've not checked with other formats
• the alpha blending and testing one only has blending work (and it only works right with my gamma correctness branches as that's an operation that needs to happen in linear space).

I might find more. I'm not going to investigate them right away while I'm still dealing with other stuff, but it seemed prudent to at least write them down somewhere.

[AnyOldName3]

An even clearer example of the effect on midtones is the OSM example. This one doesn't need any alteration as it doesn't directly specify the shaders or textures, and lets the VSG set them up itself, but still ends up wildly different except for where the light hits it straight on:

Before (not gamma-correct)

After (gamma-correct)

For apps that have their scenes set up in other software, this will help make things look more realistic and more consistent with other renderers, but for scenes created for a specific VSG app, things will get brighter. If people have already compensated for things being unnaturally dark by boosting lighting etc., they may end up too bright, and need tweaking to be suitably dim again. There's not much we can do about that except mentioning it in the release notes, as the amount of compensation required will depend both on artistic taste and the typical angles that surfaces are compared to any lights, so it's not a fixed brightness scale. It'll be better once this is behind us, but it's just a shame that the VSG wasn't gamma-correct from the start.

At least I've got some good screenshots to show OpenMW people when they suggest that we can simply make Morrowind gamma-correct and it'll always look better and no one will need to manually adjust the placement, brightness or existence of any lights.

[robertosfield]

The original has more pop, could it be that the default ambient light level is too high for the gamma corrected version so looks more washed out?

[AnyOldName3]

I'd say it's mainly popping in the same way as a teenager playing with Reshade sliders or Instagram filters can make things pop by blowing out the contrast. I don't think it's a good kind of pop. There's a way to calculate what the ambient lighting should be under the assumption that the object's inside a uniformly-emissive sphere the same colour as the clear colour (which works in much the same way as not using ambient and using a skybox for image-based lighting), but I think the main difference we'd notice if we did that would be that things were more blue with blue-tinted ambient.

All that said, vsg::createHeadlight() isn't creating perfectly equivalent lights between the two. Both the diffuse and ambient light colours are white, so wouldn't be affected by sRGB conversion, but the intensity multiplier makes things more complicated. Obviously, when it's multiplied in, $0.05\times\text{white}$ and $0.95\times\text{white}$ mean different things if they're interpreted as sRGB or linear values. It's typical for light intensity multipliers to be in linear space, but they were basically being treated as sRGB with the old approach. It looks intentional that the headlight intensity sums to one between the two parts, so just putting in the linear equivalents ($0.004$ and $0.890$), which don't sum to one could leave things gloomy. I guess that's effectively what's been happening all along, which would contribute to why the non-gamma-correct screenshots are gloomier. Also, it means the screenshots I presented here literally have more than ten times as much ambient light in the gamma-correct versions, but light isn't perceptually linear, so being ten times brighter doesn't mean much.

This is gamma-correct with the tweaked intensity values from above:

It's a little bit dimmer than the other gamma-correct screenshot, but it's still a long way away from how the non-gamma-correct one was.

This is gamma-correct with no ambient at all:

The middle's a bit brighter (as I made the diffuse intensity $1.0$) and the edge is a little dimmer without ambient, but it still doesn't have the unnatural amount of contrast that the non-gamma-correct version did.

[AnyOldName3]

I've got all the examples in the vsgExamples repo looking how they're supposed to with the colour space changes. I still don't have access to push to the ColorSpace branches on the upstream VSG repos, so this is all available in the ColorSpace2 branches on my forks.

Most of the changes were just switching colour literals to go via vsg::sRGB_to_linear, changing the VkFormat of some images and tweaking the intensities of lights (which are typically linear in gamma-correct renderers, but were effectively sRGB before in the VSG due to everything being done in sRGB space).

A few notable inconsistencies are:

• Dear ImGui is currently entirely sRGB-unaware, and in such a way that it's difficult to work around. This has been something that's been on their tracker for years, but the maintainer's never got around to deciding what to do about it. There's a pull request from 2019, but there were still open questions, and it stalled before being a complete solution, so it's not enough just to use a version with the PR applied. In the meantime, I added a function to vsgImGui to convert a theme from sRGB to linear RGB, which puts a dent in the problems. It's not perfect, though - the colours get quantised to eight-bits-per-channel before they're sent to the GPU, which isn't good for linear RGB, and widgets like colour pickers will look wrong.
• The new coordinate space example probably wants the two solar systems to be moved further apart from each other. As we're no longer unrealistically dimming faint light, the planet in between the two suns is now much more well-lit on its dark side, which probably isn't what we want.
• Despite it being a popular misconception that it's always bad to do colour gradients in sRGB and good to do them in linear RGB, neither looks brilliant, and lots of the examples have gradients. Switching the colour space that the vertex and fragment shaders run in has changed from one kind of ugliness to another, and it's not necessarily the better kind of ugliness. For everything in computer graphics except colour gradients, linear RGB is the better space to blend colours in, so this is a sensible compromise for now. Longer term, though, it might be better to encourage people to do gradients in a gradient-friendly space like Oklab. It's probably not worth worrying about, though, as most people don't need gradients and wouldn't notice any problems even if they did.

[AnyOldName3]

Most of the time with the VSG, vertex colours are three or four component vectors of floats, so the obvious right choice is to convert them to linear space upfront so there's no cost to the vertex shader. In fact, there's already room for optimisation here, as a 16-bit UNORM or half float would be plenty of precision for colour whether or not it's linear.

However, vsgPoints looks like it's designed to deal with a lot of data, and already opts into using four-component 8-bit UNORM vectors for vertex colours. The whole point of sRGB is to allow colours to be quantised to eight bits per channel without ruining them, so that's been fine until now, but simply using the same approach as everywhere else and making them linear won't be good as linear colour needs around eleven bits per channel to get the same precision across the human gamut. In an ideal world, we could just set the VkFormat for the vertex buffer to an sRGB variant, and some hardware does support that, but it's only AMD hardware - Intel, Nvidia and all the mobile vendors skip this optional feature. That leaves us with a few options:

• accept undesirable quantisation artefacts except on AMD hardware (and hope that eventually other vendors also start supporting sRGB vertex buffers).
• burn more memory on VK_FORMAT_R16G16B16A16_SFLOAT or VK_FORMAT_R16G16B16A16_UNORM colour attributes.
• eat the cost of an sRGB conversion in the vertex shader for vsgPoints
  • and maybe have a shader define to control this, which could also be the case for the standard VSG shaders

It looks like there's enough flexibility that whichever choice is made, user applications will be able to opt out of it and use one of the others, e.g. by replacing the stock shadersets and providing their own vertex data, so it's not a disaster if we choose badly, but obviously it's better to have a good out-of-the-box experience, so it would be better to make the decision with some information about who's doing what with vsgPoints so far.

[AnyOldName3]

By the way, there are a few non-colour-related fixes that might want cherry-picking onto master before the colour stuff is merged:

66a8adb fixes some memory corruption caused by mixing and matching glslang builds with different ABIs.

e066d18 prevents doubling line breaks when loading and resaving a .vsgt file on Windows.

bca81d4 fixes recompiling SPIR-V shaders - previously the new bytecode would be appended onto the existing bytecode, which would give invalid opcode errors.

[robertosfield]

I have just done a quick review of the above changes and they look fine to me. What would be the most convenient way to pull these in? At my end a PR would be most straight forward.

[AnyOldName3]

You could either cherry-pick those commits straight onto master (you'd need to add my fork as a remote, fetch it, and then git cherry-pick 618adb etc.), or I could cherry pick them onto a branch and open a PR for that branch.