@troy_s Such an interesting topic and so many great insights. More researching, fiddling, and potentially a little modeling on the side for me.
@troy_s The AgX mechanic is so elegant that it is even possible to grasp the core mechanic by only looking at the OCIO config file. That's quite the achievement! Thanks for the detailed explanation, which fills the last few gaps.
I can only talk from my experience of shipping games with various picture formation chains in custom tech, and I appreciate this "movement". There was a lot of pain involved in the past, so at least I'm very well aware of the importance. 😄
@troy_s Even better! Thanks. 😄
After the experiments of the last days, I had to integrate AgX by @troy_s.
Very eye-pleasing results and excellent control when color grading in Resolve. Here's a comparison between AgX (Base) and in combination with an aggressive color grading LUT authored in Resolve.
@troy_s This is the full set of parameters I ended up testing with:
w_0 = 200, w_1 = 1
o_0 = -0.0066
p_0 = 0.02205, p_1 = 0.08
Constants for the above parameters:
s_0 = 0.103944
k = 3.627926
o_1 = 0.449268
y_0 = 0.0
p_0 chosen so that y_0 ends up being zero, so the exact value for any set of input parameters is:
p_0 = p_1 / k
@h3r2tic @troy_s Here is the first transfer function I came up with based on XLog (https://colab.research.google.com/drive/1NwjaD0NzNMzQeNQqZECj33PdcYGkeBM4#scrollTo=gSA0nfc974mp):
I took the default values of XLog with w_0 set to 200 and p_0 shifted to avoid negative values (see computeNonNegativeFit) - keeping the linear toe.
I did some quick tests with Tony vs. the reference images and my testing scenarios, and they turned out to be very promising, given my rather heavy usage of small LUTs. Grading also seems to respond well. 😃
@troy_s @h3r2tic Sounds like the perfect solution to my problem; thanks a lot. I will give both options a spin!
@troy_s @h3r2tic Thanks for the detailed explanation, Troy. I noticed the issue with the negative values the other week, and it turned into a TODO on my list. It indeed induces a shift, at least with the encoding and overall LUT handling I use.
I opted for LogC encoding since it resulted in a good wheel response in Resolve. And, regarding what @h3r2tic asked, I'm using a completely unified system based on the same LUT type for grading and for the "tone mappers", primarily for blending purposes.
@LxLasso @camkerr Yey, another tone-mapper variation! 😁
As far as I can tell, the ACES 1.3 gamut compression works well, keeping the ACES look without introducing another look on top of it, like the "blue artifact fix transform" does. It only touches the problematic colors without increasing the brightness of the purple spheres and the portal in the background (and the whole image, honestly).
For further reference, the input transform can be found here:
If you happen to build your tone mapping from the ACES reference implementation, I can not recommend applying the "Blue Light Artifact Fix" LMT highly enough. For emissive objects, pure blue otherwise almost directly clips into the purple areas of the gamut:
The fix is a simple matrix transformation applied before the RRT using the AP0 primaries.
Some more fun 😀 details in the ACES community:
Here's a short video showing ray-traced shadows applied to local light sources in the volumetric fog system.
I finally plugged the voxel ray tracer into the volumetric fog system. It's been a long time with just uniform fog since I ultimately got rid of shadow maps.
I've just finished dropping Tony McMapface by @h3r2tic into IOLITE. Quite pleasing results so far. Its lightness works hand in hand with the GI, with less crushed shadows and overall contrast. 😀 Voxel scene by Zach Soares.