To honor the blender filmic look you would need some kind of LMT to modify the look right before the output transform at the end. I don’t know how you’d go about creating that or if it exists already.
What’s your general goal of wanting to use ACES if you want the Filmic look anyway? Why not just use the filmic output transform at the end?
Although I would find it very risky to go this route, at least you would view in all tools the same view transforms.
A third option would be to stay in Blender (Filmic) as in option 1. and import the finished comps as EXR (linear-sRGB) into Resolve and do the grading and mastering there.
You can use the Filmic LUTs there as well or use Resolve’s RCM2 or ACES with it’s view transforms.
The moment you change the view transform you also alter the look of the film. This can be okay or a problem and should be tested first.
We would like to composite CGI (made in blender) with real camera footage (different cameras with different colorspaces). We thought ACES could be useful for camera matching and we are trying to figure out how to add blender in the ACES pipeline. We aren’t interested in keeping the filmic look for the real footage, and after some testing using 100% ACES in the pipeline it’s not working for our eyes.
After reading Mr. Brylka’s Blender-ACES approach (thanks!) & this discussion devtalk.blender(dot)org/t/blender-support-for-aces-academy-color-encoding-system/13972/193
I will summarize in my own words and understanding:
ACES v1.2 comes with a lot of issues in it (wide gamut compression, etc)
Blender has its “limitations” in a ACES pipeline
I’ve also read this really interesting reflection chrisbrejon(dot)com/articles/ocio-display-transforms-and-misconceptions/
sure, you can grade in a log space, but the Grade node and the ColorCorrection node expect a linear working space, right?
I would see it like working with log images in Photoshop under a SoftProof LUT: It’s a workaround, but PS tools are expecting pixel values between 0% - 100% and are harder to control when they are all compressed to a small range in a log encoded image.
Or take Resolve:
Another way to look at it is to use a 0-1 ramp from Nuke as an EXR and DPX (logC for example) and load them into Resolve (without ColorManagement).
Lift, gamma and gain work best on the linear ramp when you check the waveform.
And the log tools shadow, midtones and highlights are working best to manipulate the DPX image.
Nothing is holding you off to use whatever combination you like, but tools are made for a certain type of input. So you are right, sometimes you can achieve interesting results, other times you might fight against the material.
As far as I’m aware lift, gamma, gain has always been an essential part to color grading and I don’t know any colorist grading in linear aside from switching temporarily to it to adjust scene exposure perhaps but not tonal/artistic control. Maybe this is different in the CG/VFX industry but you can make both methods work I guess.
The latest OCIO config of ACES does support the Reference Gamut Compression. Haven’t tested it yet though.
Workflow wise limitations in Blender can be worked around by adding the RRT+ODT as a display transform into the Blender filmic config so you can keep working in linear srgb but previs with the ACES look so it will match what you’ll end up seeing in Natron. This isn’t the same as rendering in ACEScg ofcourse but this can be a choice.
I’ve tested this setup some time ago and worked quite well from what I could tell. Sharing my config here.
As to having the look of other rendering systems inside ACES maybe this topic can help.
For the rest of the workflow I’m with the what Daniel suggested above this post.
I only said, the grade and color correction nodes in nuke expect by default a linear working space.
For the Resolve example: Its only showing where the grading tools “work” on the image data.
Sure, I also don’t know any colorist in Resolve who is working in Lift, Gamma, Gain with linearized image data.
One approach could be to read all the camera footage into (free) Resolve, possibly applying the ACES gamut compression if needed, and export as ACES-2065-1. That would bring all your stuff into a unified color space.
Yea I know, I looked it up before making that suggestion initially and Natron does already support OCIOv2.1. I didn’t do a proper difference test yet but dropping it in Natron on the lightsaber exr gave me the same result as in Resolve with ACES Transform node ACES1.3 + RGC judged by eye.