Hi guys! Where can I find the exact info about the s-curve used for tone mapping in ACES to build this effect in Nuke node in case in missed,
Hello,
I think Alex Fry did an implementation in Nuke: Pure Nuke ACES RRT & ODT — AlexFry.com
And Jed Smith also: nuke-colortools/toolsets/ACES at master · jedypod/nuke-colortools · GitHub
Regards,
Chris
ok, I’ll try to dig it out, thank You, Chris!
Bear in mind that the ACES rendering is more complex than just a tone curve. The number of nodes in the implementations by @alexfry and @jedsmith will give you an idea.
I agree with you that the ACES rendering is complex. I would also say that the resulting image does not justify the complexity. To elaborate with an example:
Let’s start with this set of test swatches varying around the Arri Wide Gamut 3 gamut boundary.
First is the ACES 1.2 “Rec.709” image formation:
Next is the test image data clipped to ACEScg gamut, the ACES tonescale spline applied, and converting to Rec.709 gamut.
Next is a formula based generic tonescale function I spent a couple minutes eye-matching to the ACES spline (even including the absolute black mapping of scene-linear 0.002 → display-linear 0.0). Note this approach could easily be implemented in 10 lines of shader code.
Do you think the extra complexity is worth the result @dmitryshoumkin?
Here is the nuke script if you want to experiment for yourself.
ACES_1.2_Complexity.nk (222.0 KB)
4 Likes
Hi guys! Thank you for colloboration, it usully helps to find an appropreate solution. That’s really a bit complicated stuff!
I can say what temporary but working solution I found for my urgent needs.
Being actually lighting and compositing artist (with the bg of physics), I have to compose ACES with non-ACES multychannel .exr in current project. To awoid darkening (coused by lack of s-curve in linear IDT somehow), I have to compensate it.
Since sRGB IDT works as expected: it does pimaries convertion + tone-mapping nicely, one can dig the data out from working sRGB mechanism this way: saving the reference frame .exr (from non-ACES Nuke) to sRGB colorspace .exr (to preserve high dynamic range), then comparing these (two identical images but in different colorSpaces) with MatchGrade Nuke node. It anilizes the difference and calculates cc to compensate it, and stores the result as LUT. Then I use the OCIOTransform node (with this .csp file) for all non-ACES channels to make the job.
This method is too far to be precise though. First I planned to find the needed LUT in ocio.config file, then about writing an Expression Node with the exact s-curve equation, but did not find it.
One good thing is that I found an acceptable (for now) solution (LUT file work faster then expression anyway), but it lacks accuracy and does not work universally. I thought if I chose a reach color hdr file and save LUT with large number of points, I would get an universal node, but somehow it work the different way. So I have to regenerate this LUT then it stops giving an appropeate result.
Thank You, Jed for example script, I’ll try to improve my understanding of the subject.