Simplify haze evaluation

[rreusser]

This PR greatly simplifies the haze evaluation—both in terms of code and computational expense—with very little change in visual effect.

Preface: I’m well aware of the risk of code-golfing this into oblivion until no one can make sense of it, but I think the following change removes most of the negative aspects @ansis was very legitimately concerned about, while maintaining reasonable motivation and resulting in a much more self-contained and easy to maintain application of this coloring.

Update: I've illustrated the following argument in an interactive notebook

The existing process for computing haze is as follows:

1. convert the fragment color from srgb to linear
2. add haze to that color
3. tonemap to avoid blown out fully saturated rgb values
4. convert linear back to srgb

The process makes reasonable physical sense but involves a lot of steps and also lead to small frustrations like having to fight against tonemapping subtly darkening colors. It also raises questions like: do we really want ad hoc color space conversion and tonemapping in the middle of a special purpose function?

This PR maintains the above motivation while consolidating the evaluation into a single step.

For varying values of haze h = (0, 0.01, 0.05, 0.25, 0.5), the red curves below illustrate the above four-step process, with input colors on the x-axis and output colors on the y-axis. The tonemapping and color computation functions are given by:

(with k = 8.0 in the smooth min tonemapping function). Based on @ansis' observation that we could just scale the curve to pass through (1, 1) exactly, the black lines illustrate the simplified equation (with γ= 2.2):

https://www.desmos.com/calculator/nhgqknt2w0

Finally, we can further fudge the gamma just a bit since exceptional physical accuracy is not needed. If we use γ= 2, pow() calls disappear and we're left with a single square root as the only transcendental function:

(the x^4 in the denominator is a small touch which prevents the colors from getting too squished together near (1, 1). Without it, they are closer to tangent and visual details is lost.)

Benefits of this approach:

• calls to exp2, log2, and two calls to pow are reduced to a single sqrt (all repeated 3x for r/g/b)
• Significantly less shader code
• avoids the need to pass an extra varying to manage tonemapping
• Output is strictly lighter than the input, so that we don't have to worry about undesirably darkening colors by tonemapping
• It follows the original motivation, which I think is reasonable, while eliminating a lot fo the negatives

The difference in appearance is negligible. Darkening of pure whites due to the tonemapping is just about the only difference which can't be compensated for by a very slight change the parameters.

Original:

Simplified:

(Strictly speaking, I ever so slightly modified the exponent in the cpu-side approximate srgb-linear conversion. The above shows power 2.2. I've PR'd power 2.0. The difference can entirely be compensated for by very slightly changing the input color. The difference does not seem important; I only note it to be precise.)

To be addressed in followup: consolidating and refactoring into a shared vertex/fragment prelude.glsl.

[karimnaaji]

Nice simplifications! Did you also do some quick visual checks on styles different than satellite? I think the color tones of satellite is rich enough to cover a lot, but just to confirm.

Left one nit on naming, otherwise 👍

[karimnaaji]

Just noticing this now, and not a change from this PR, but did we not name this function appropriately? As the output is both opacity and haze naming it fog_haze seems counterintuitive, it might be an overlook from the optimization when moving things fragment -> vertex.

[rreusser]

@karimnaaji I think the only major difference that wouldn't be caught by satellite imagery is that for light styles, this function struggles just a bit more at very bright values since everything gets squeezed to a point at pure white, rather than tonemapping darkening and maintaining a bit more separation between colors as they become brighter. Due to the somewhat lower utility of haze for stylized maps, I think this is an acceptable tradeoff for avoiding frustration with trying to constrain tonemapping to just the fog layer.

[karimnaaji]

@karimnaaji I think the only major difference that wouldn't be caught by satellite imagery is that for light styles, this function struggles just a bit more at very bright values since everything gets squeezed to a point at pure white, rather than tonemapping darkening and maintaining a bit more separation between colors as they become brighter. Due to the somewhat lower utility of haze for stylized maps, I think this is an acceptable tradeoff for avoiding frustration with trying to constrain tonemapping to just the fog layer.

Yes that seems fair, thanks for checking! And I agree that haze really shines with satellite-based imagery.