blog_posts/minimal_agx_implementation

[giscus[bot]]

blog_posts/minimal_agx_implementation

Contains a minimal implementation of Troy Sobotka's AgX display transform, which is easy to drop into any existing codebase - especially for testing purposes.

https://iolite-engine.com/blog_posts/minimal_agx_implementation

[Opioid]

Thanks for this code! How did you compute the matrices? I guess linear sRGB space is assumed? I am interested in re-deriving the inset matrix so that it works for AcesCG.

[begla]

You're right that it's a little confusing.

I quickly rechecked the official OCIO config, and your interpretation and usage are correct. The immediate output ("AgX Base" in the config file) is directly interpreted as non-linear Rec. 709 with a 2.2 gamma curve applied to it. I was referring to the output after the agxEotf as being linear since I did not "bake" this part.

For me, it's natural to stay linear in the shader and to use sRGB RTs; hence I added the linearization in the agxEotf function. So, if you're not using a sRGB render target, like it's the case for the shadertoy, the shortcut is, as you pointed out, to comment the line.

[Opioid]

Thanks a lot for clarifying!

[Luke25361]

This is fantastic, thanks so much for sharing 😄

I also have a question about the EOTF part. Is there a reason the linearization happens after agx_mat_inv has been applied? I ask only because I noticed it happening before this step instead in MrLixm's implementation, and I'm not yet familiar enough with OCIO to fully understand what's going on in the original config file.
There's definitely a (subtle-ish) difference in output when doing the linearization before vs after, though I'm struggling to describe it...it's like the dark colours get darker and/or more saturated...

[begla]

The application of the outset, as described in the post, was recommended and inserted by Troy, the original author of AgX, after reviewing my code. The last time I checked, it was not even part of the "official" config file yet.

[Luke25361]

Gotcha, am just now realising that that's what was meant by "full round trip"
Thanks again for sharing this :)

[hybridherbst]

Thanks for providing an easy-to-follow implementation!
I'd have two questions:

• Is there a reference viewer somewhere to compare results to?
• When using a toneMappingExposure multiplier, would that be just a multiplier before applying agx or would it be elsewhere?

        color *= toneMappingExposure; // apply an exposure multiplier
        color = agx(color);
  

[begla]

That's a perfectly valid way to apply exposure!

Regarding a reference render, I used the official OCIO config and Blender to validate the results, which is also relatively easy to set up.

Troy's testing imagery collection provides some useful sample images for doing any form of comparison/validation:

https://github.com/sobotka/Testing_Imagery

[hybridherbst]

Thank you! Do you know if the Blender 4.x implementation of AgX (which seems to be the default tonemapping by now) is different to your approach?

[begla]

I'm not aware of any changes to the reference implementation, but I also have not checked the actual 4.0 implementation in detail yet.

[donmccurdy]

From discussion during development for three.js, one difference is the "guard rail", which has some effects you can see here:

mrdoob/three.js#27366 (comment)

In our case, it didn't seem feasible to include that in a realtime implementation, and the differences are acceptable. Blender screenshots were generated with a custom bash script and OCIO.

[Calinou]

Hi, thanks for this code! It seems to work quite well in my Godot prototype 🙂

I have two questions:

• How is the whitepoint defined? Other tonemapping methods like Filmic and ACES have an adjustable whitepoint, so you can choose beyond which point highlights will be blown out (increasing whitepoint will make the scene a bit darker as a result). I haven't found an obvious way to do this with the AgX implementation provided here.
• Could you add a license to the code, please? This ensures we can use it in projects legally. For context, I'm interested in integrating this in Godot to provide AgX tonemapping support. Godot is MIT-licensed, so the code would need to be under MIT or a compatible license.

[begla]

That’s great! 😊

I’ve added an MIT license header to my implementation on the website and a note that all values used for deriving the implementation are sourced from Troy’s OCIO config file.

Regarding the white point:

It should be possible to implement the standard parameters by adjusting the min/max EV-based normalization (black and white points) after moving to log2 space and by scaling the open domain values right beforehand (exposure). The values I used are based on the values in the mentioned config file.

You can find inspiration for tweaking AgX by looking at Troy’s config generator. The functions handling the open domain to log2 space conversion should be the right place to start looking.

https://github.com/sobotka/AgX-S2O3/blob/main/AgX.py

[begla]

As a reference, here's an option to provide a tweakable black/white point in the open domain for the given implementation (values chosen to match the inverse of the default values):

const float black_point = 0.00017578;
const float white_point = 16.2917;
const float min_ev = log2(black_point);
const float max_ev = log2(white_point);

[Calinou]

Thanks a ton! I've opened a pull request for Godot: godotengine/godot#87260

[begla]

@Calinou Very cool, glad it worked out! 🙌

[donmccurdy]

Thank you for sharing this work!

During review of an implementation in the three.js open source library, a question was raised about the luminance coefficients: 0.2126, 0.7152, 0.0722. These appear to be the standard coefficients for BT.709 primaries, but (to my understanding) we're working in a log space derived from Rec.2020 when applying the AgX looks. Do you know whether that's correct, and (if so) why that would be?

[begla]

At the time, I tried to match the output of the OCIO configuration file Troy initially provided.

https://github.com/sobotka/AgX/blob/main/config.ocio

I remember doing some backtracking regarding the ASC-CDL transform ("CDLTransform" in the config file) used for implementing the looks. The ASC-CDL does not incorporate a saturation parameter in most openly available documentation. I also suspected some context-sensitive behavior according to the involved primaries and color spaces.

But, as far as I can tell, the luma coefficients in the "CDLTransform" of OCIO are fixed and match the ones I ended up using:

https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/aadf595946ed8a27d69ad0e338d0a8b779465707/src/OpenColorIO/transforms/CDLTransform.cpp#L302

[donmccurdy]

Thank you @begla! I haven't been able to find documentation for ASC-CDL v1.2 about this either, but that sounds like a good explanation of the choice to me. :)

[nxrighthere]

Thank you for the code! Here's the implementation for UE 5.3 https://gist.github.com/nxrighthere/eb208dae8b66dbe452af223f276e46cc

[bWFuanVzYWth]

vec3 saturate(vec3 v) {
    return clamp(v, 0.0, 1.0);
}

vec3 agx_curve3(vec3 v) {
    const float threshold = 0.6060606060606061;
    const float a_up = 69.86278913545539;
    const float a_down = 59.507875;
    const float b_up = 13.0 / 4.0;
    const float b_down = 3.0 / 1.0;
    const float c_up = -4.0 / 13.0;
    const float c_down = -1.0 / 3.0;

    vec3 mask = step(v, vec3(threshold));
    vec3 a = a_up + (a_down - a_up) * mask;
    vec3 b = b_up + (b_down - b_up) * mask;
    vec3 c = c_up + (c_down - c_up) * mask;
    return 0.5 + (((-2.0 * threshold)) + 2.0 * v) * pow(1.0 + a * pow(abs(v - threshold), b), c);
}

vec3 agx_tonemapping(vec3 /*Linear BT.709*/ci) {
    const float min_ev = -12.473931188332413;
    const float max_ev = 4.026068811667588;
    const float dynamic_range = max_ev - min_ev;

    const mat3 agx_mat = mat3(0.8424010709504686, 0.04240107095046854, 0.04240107095046854, 0.07843650156180276, 0.8784365015618028, 0.07843650156180276, 0.0791624274877287, 0.0791624274877287, 0.8791624274877287);
    const mat3 agx_mat_inv = mat3(1.1969986613119143, -0.053001338688085674, -0.053001338688085674, -0.09804562695225345, 1.1519543730477466, -0.09804562695225345, -0.09895303435966087, -0.09895303435966087, 1.151046965640339);

    // Input transform (inset)
    ci = agx_mat * ci;

    // Apply sigmoid function
    vec3 ct = saturate(log2(ci) * (1.0 / dynamic_range) - (min_ev / dynamic_range));
    vec3 co = agx_curve3(ct);

    // Inverse input transform (outset)
    co = agx_mat_inv * co;

    return /*BT.709 (NOT linear)*/co;
}

This is not a fitting, but the exact solution I obtained through algebraic simplification.
https://github.com/bWFuanVzYWth/AgX

[Ivan-Veselov]

But what is the point of pow(val, vec3(2.2));? The comment says that its for linearization, but color was never gamma-encoded in the first place. Plus EOTF is usually a part of hardware, and all rendering APIs and engines expect encoded color values as outputs not decoded display linear values. I can only assume that AgX machinery somewhere inside encodes color with an equivalent of pow(val, vec3(1.0 / 2.2));. But that looks strange, cause why whould one make it a part of a tonemapping operator when there are other color spaces besides sRGB, like Rec709 which has the same primaries and white point but different trasfer function (approximately 2.4 power)? Could someone help me out understanding this?

[Ivan-Veselov]

Saw the discussion about this in the replies to the first comment after posting my. So, looks like indeed AgX somewhere inbetween kind of applies power function. Still weird though.

[allenwp]

Your polynomial is a pretty great equivalent to the original curve! I'm looking to make a polynomial approximation of the Blender AgX sigmoid curve, which is similar to this one. I've been trying with different sample sizes as input to a calculator, with or without some extra padding... and a lot of trial and error! What tools/calculators/process did you use to get this formula?