Explanation/article anywhere?

[stgatilov]

Hello!
Thank you from sharing this with everyone =)

Some people would like to include AgX tonemap into a game (TheDarkMod). They gave me some shader composed of many pieces from different places over the internet, with various hardcoded numbers included. I'm trying to understand what it is all about and if it is even correct... And all references lead me to this repo.

Is there any kind of scientific article, website article, blog article, forum post, etc. --- anything that derives AgX and explain why and how it works? Could you please add such a link into readme?

[sobotka]

Probably best if I try to answer questions framed from a place that makes sense to you. I have converted this to a discussion.

[stgatilov]

Actually, I am pretty far from this topic.

We have an old game with gamma-incorrect rendering (basically Doom 3) but float16 color framebuffer.
For some reason, people insist on applying PBR-era techniques to this =(
Here is what I see in the shader.

First I see sRGB to linear conversion (component-wise) which does this. It is a bit more complicated than typical pow(color, 2.2).
Since our render output does not make any physical sense anyway, I suppose sRGB or simple gamma conversion here is just a matter or what looks better.

Then there is multiplication by some magic matrix which definitely lacks proper explanation:

        0.842479062253094,   0.0423282422610123, 0.0423756549057051,
        0.0784335999999992,  0.878468636469772,  0.0784336,
        0.0792237451477643,  0.0791661274605434, 0.879142973793104);

The matrix is close to 0.79 * Identity + 0.07 * AllOnes, but in reality some off-diagonal elements are about 0.078 while others are 0.042.
Initially I thought it was conversion to some well-known color space, but now I think it is not. I guess it averages color components a bit, so that e.g. "pure red" becomes "red + a bit of white". I guess it is important so that high-intensity colors gradually desaturate and turn into white.
What I don't understand here is why off-diagonal elements are different. Perhaps it has something to do with the fact that RGB have different intensities (e.g. in brightness/luminance computations green is always prevalent).
It would be great to know how this was obtained, since now it is really tempting to just replace it with 0.79 * Identity + 0.07 * AllOnes =)

Then color components are converted to logarithmic scale (base 2) then linearly rescaled so that [-12..4] logarithm turns into [0..1] interval.
I guess this is where the tonemapping itself happens, i.e. compressing HDR into LDR.
And I suppose specific values in the interval are not important here, so e.g. replacing -12.47393 with -12 won't make much difference.

Supposedly the logarithm alone is not a good tonemap, so it is followed by applying some weird-looking curve.
The function is tagged as "sigmoid" for some reason, but I think it monotonically maps 0..1 to 0..1 (I guess it becomes almost sigmoid together with logarithm). At least I hope so =)
Since AgX claims to model how film paper records incoming light, I think the function does precisely that. Trying to understand this is useless, it just makes sure the tonemapping looks good in general (aside from being mathematically sound).

Then there is "look" function with parameters slope, power, sat.
Cryptic comment "ASC CDL" led me to wikipedia. I guess this is where artistic adjustment takes place. So we can choose some parameters that we like as default, and perhaps later allow mappers to override then on per-area or per-level basis.

After that the color is multiplied by inverse of the magic matrix described above.
The matrix has negative coefficients, so I wonder why it can't produce negative values?
And why this inverse transform is even necessary if the original magic matrix exists in order to "blend" color components into each other.

[stgatilov]

I'm trying to play with the shader I got.
I have realized that conversion from sRGB to linear happens not before tonemapping, but after it.

So the AgX tonemapping function which marks its input as "Linear BT.709" actually gets the output that we usually send to the monitor (i.e. in sRGB/gamma space). Which is questionable: even though the engine does math as if it was linear space, the actual content is more suited to be sRGB output.

And then its output, which is also marked as "Linear BT.709", is passed through linear-to-srgb conversion. I am a bit confused since different versions on the internet supposedly have output in different space (e.g. here output is srgb). But I suppose this is OK for this specific analytic curve implementation.