Improve how the tone mapper interacts with the linear pipeline

[illwieckz]

Here is the panorama:

First, We have a 10 year ongoing effort for:

• using more physically correct equations when baking maps
• preventing color banding, the latter means we want more details in high lights and in shadows, because of how the human eye works, the main concern is about the shadows

The linear pipeline addresses this and the trick of storing lightmaps in sRGB also improves a bit the color banding problem by biasing the precision in favor of shadows. In the future using HDR light maps may improve that even more.

Then, we have a will for having adaptative lighting, where the exposure of the render is adjusted to the amount of lighting in the scene: low exposure on sunny outdoor to see something, high exposure in dark rooms to see something, like the human eyes naturally does.

I believe the tone mapper Reaper implemented is a fundamental brick of that adaptative lighting feature which is highly wanted. Many thanks to Reaper for working on this and for having already achieved this first step.

Now, a tone mapper isn't exactly physical, but light our colorgrading feature, such effect can be wanted, it's fine. As long as we can do it over our linear lighting pipeline, this is good. People like special effects and pleasing transformations (I'm am among them).

So, now we need to make them work together the best way possible, especially if we want adaptative lighting.

[illwieckz]

Just to be sure, before tweaking things, we must be sure we have no bugs, so I triple checked things. This is not a distrust of people's work, it's just a check. And in fact I found a bug I introduced, so this is good.

Now that this bug has a fix, it looks like everything is correct:

• The tone mapper implementation by Reaper is correct.
  Just to be sure I reworded it to shape it exactly like it is in Timothy Lottes' slide and it's the exact same.
• The chaining of tone mapping and color conversion is now considered correct, considering this discussions assumes the fix is merged. This also have been checked against Timothy Lottes' slides and other sources.
• The configuration values used in the tone mapper are not unusual, they may or not fit our needs (we may want to tweak them), but they aren't unusual.

About the configuration values, the implementation by Reaper used this configuration:

a = 1.6 # contrast
d = 0.977 # highlightsCompressionSpeed
hdrMax = 8.0
midIn = 0.18 # darkAreaPointHDR
midOut = 0.267 # darkAreaPointLDR

The Timothy Lottes' slides didn't used those values, for example slide 81 used:

a = 1.3 # contrast
d = 0.995 # highlightsCompressionSpeed
hdrMax = 64.0
midIn = 0.18 # darkAreaPointHDR
midOut = 0.0225 # darkAreaPointLDR # 0.18 / exp2(3.0)

But this is for “10-bit output instead of 8-bit” (quote from the slides). It isn't that far anyway.

Here is a third-party Lottes tone mapper implementation that uses close values:

• https://gist.github.com/MrLixm/96e24bdbf643dbf24cd098be446829cc#file-maxrgb_lottes-py-L21

The values here are:

a = 1.65 # contrast
d = 0.977 # highlightsCompressionSpeed
hdrMax = 16.0
midIn = 0.18 # darkAreaPointHDR
midOut = 0.267 # darkAreaPointLDR

The contrast is almost the same as what we have, and the hdrMax is just increased compared to us, but lower than Lottes' example.

Here is another third-party Lottes tone mapper implementation that uses the exact same values we first had when we merged Reaper's implementation:

• https://gist.github.com/Pikachuxxxx/136940d6d0d64074aba51246f514bd26#file-tonemapper-frag-L31

The values here are:

a = 1.6 # contrast
d = 0.977 # highlightsCompressionSpeed
hdrMax = 8.0
midIn = 0.18 # darkAreaPointHDR
midOut = 0.267 # darkAreaPointLDR

So, we can assume those values are correct. It also shows that it is common to tweak them for the game needs.

While we may tweak these values, and our experiment showed that reducing hdrMax helps us avoiding losing colors in high lights, they don't look inherently wrong and look safe to use as a start, before we adjust them to our needs, if we need to.

[illwieckz]

Here follows screenshots of the hangar28 map. To make it easy to evaluate color banding in low lights, I multiplied the screenshot color by 8, so we don't get fooled by our screens possibly not being able to render very low grays. I'll post the original screenshots in the next post for reference.

The screenshots for the naive pipeline comes from the public build. We can spot issues coming from the buggy small light attenuation, but those issues are very obviously distinguishable from color banding problem, so I did not rebuilt the map the naive way, this is good enough to observe and diagnose things.

The screenshots for the linear pipeline comes from a local build on my computer. I may host it on the RC server if needed.

So, here is the naive build, no tone mapper:

Here is the naive build, with tone mapper:

We can see how most of the wall is almost pitch black. The color banding is in the lightmap itself, so the tone mapper just operates on the rest of the colors. It's hard to configure the low light behavior of the tone mapper with maps built the naive way because the data is missing in input to begin with.

Now is the linear build, no tone mapper:

We can see how there is information almost everywhere in the lightmap. Except a few pixels, the linear pipeline produces the information and the sRGB lightmap storage carries the information we want to produce, preserve and provide.

Now is the linear build, with the tone mapper using our current configuration:

An heavy contrast is applied, so heavy that half the information is now lost.

That's why we need to tweak the tone mapper, so we can preserve more information. Help is needed.

[illwieckz]

For reference, the original screenshots:

Naive build, no tone mapper:

Naive build, with tone mapper:

Linear build, no tone mapper:

Linear build, with tone mapper:

[illwieckz]

I'm also wondering if the tone mapper is meant to be used outside of the whole adaptative lighting pipeline. Maybe all we need to get the tone mapper usable in all cases is to finish the adaptative lighting.