ACES open source software pipeline (blender, natron)

Hi Chris,

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.

Does Natron support OCIO nodes or something like the Vectorfield node to apply a 3D-LUT? Then the described workflow is easy to setup.

But, be aware that certain highly saturated colors might shift (I saw it with reds and yellows) and the black level of the signal as well when using the so called “no-operation”. It is still a hack.

Another way I could think of is:

  • unify the camera colorspaces to acescg in Natron
  • working in blender in linear-sRGB/Rec709 (view with Filmic) and load them into Natron as linear_sRGB/Rec.709
  • now you have everything in acescg
  • more color matching might be needed, because couldn’t light the 3D in the same working space as the plates.
  • You can use the RRT &ODT of your choice.

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.

1 Like

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.

Hi, could you “simply” build an ARRI K1S1/ALF-2 OCIO Config and roll with it ?

Chris

I often refer to this thread when I talk to my colleagues about this interesting topic.

Maybe it helps a bit,

Chris

3 Likes

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.

Thanks Chris,

just yesterday I watched the amazing video from Jed about the " The Math of Color Grading in Nuke" (and I guess in most cases this also counts for Natron).

3 Likes

I don´t think this supports the Reference Gamut Compression. It is an ACES 1.2 OCIOv2 config, right ?

Thanks !

I might have misunderstood perhaps, but from that thread:

The Reference config from that same release does have an LMT for RGC and the legacy Blue Light Fix.

- !<Look>
    name: LMT - ACES 1.3 Reference Gamut Compression
    process_space: ACES - ACES2065-1
    description: |
      LMT (applied in ACES2065-1) to compress scene-referred values from common cameras into the AP1 gamut
      
      ACEStransformID: urn:ampas:aces:transformId:v1.5:LMT.Academy.GamutCompress.a1.3.0
    transform: !<BuiltinTransform> {style: ACES-LMT - ACES 1.3 Reference Gamut Compression}

Those are two different configs :

  • The CG one without the RGC, usable in production.
  • The Reference config is for developers to check their OCIO implementation.

Sounds correct ?

Chris

Yes that would be correct! Would it be a bad thing to add the LMT from the reference config to the CG config?

I don´t know… It is worth testing ! The RGC would only be available with a software which has implemented OCIOv2.1.0 ?

Chris

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.

Cool ! You did your homework ! Much better than me !

Thanks for cheking :wink:

Chris

This is all correct. The configs are for ACES 1.3 which requires OCIO 2.1 which is not currently supported by any DCC software to my knowledge.

If folks are interested, I do have an OCIO 2.0 config that has Reference Gamut Compression implemented as an LMT using the LUT made by @matthias.scharfenber.

I wrote up some docs for the configs, the Gamut Compression section is here:

Here’s the relevant part:
The ANM config uses Reference Gamut Compression (RGC) to address hue shifts in CG colors. Here the RGC is automatically applied in the view transforms of the ANM OCIO config, and also baked into the output when writing out to sRGB using 3D LUTS. This is accomplished with a 1D shaper function that transforms both negative and positive input value ranges into the 0.0→1.0 domain, essentially the ACEScct function mirrorred at the Y-axis.

The VFX config in contrast does not have RGC as a view transform or output and instead uses the Nuke Gizmo.

Feel free to play with it. No warranties, and note the caveat that there are limitations of the implementation of this as a LUT (as opposed to the analytical transforms). Because of this, the way I work with it is to only use the LMT for viewing, and never for output. For that I use the Nuke node.

1 Like

Grading
Really interesting thread about the grading physical phenomena aspects in linear and grading perceptual phenomena in log. We’ll apply that in our workflow.

We thought ACEScc was the designed space for grading (as indicated in the oficial ACES documentation), but we agree: “ACEScc is quite difficult to use because it is not a physical nor a perceptual space”.

ACES pipeline

  1. We discard any Resolves approach (Resolves it’s partially free, but not open-source, our goal is implement the pipeline 100% open source-software for this project)

  2. The OpenColorIO-Config-ACES 0.2.0 approach using the LMT from the reference config it’s really interesting but maybe is quite experimental for our production, at this moment.

The ARRI-LUTs approach seems the way to go for us. But we are stuck in some points in the workflow:

  • in Blender render [.exr in srgb-liniar]
    • adding the RRT+ODT as a display transform into the Blender filmic config for the previews as suggested by Mr. Shebbe
  • in Natron Read blender.exr [FileColorspace=Utility-linear-srgb Output=Utility-liniar-srgb] →
  • → [Color Grading] (for physical phenomena)
  • → [OCIOcolospace (Input:Utility-liniar-srgb // output:ACES2065-1)
  • →Merge with real footage (previously to ACES2065-1)
  • → OCIOFileTransform (ARRI-LUT => Scene-linear WG to Log-C WG)
    • At this point the generated arri-lut gives us all these EI options:

    • Which Exposure Index should we use? Are we using the right ARRI-LUT to get the LogAWG?
  • → OCIOFileTransform (ARRI-LUT => Log-C to Classic 709=K1S1)
  • → [Color Grading] (for perceptual phenomena)
  • → Invers ODT & Invers RRT = Help needed here! OCIOcolorspace (Input:??? Output:???)
  • → WriteNode (Input Colorspace:??? Output:Output-sRGB /// Output:Output-P3D65)

We really appreciate all your tips and insights! Thanks a lot!

You’ll want to be careful with converting your gamma only because LUTs like LogC to 709 probably imply that the color space is ARRI Wide Gamut but you left off with yours being AP0.
ACES2065-1 is also not meant to be a working colorspace. It’s ACEScg wich is linear with AP1 primaries.

Don’t have a lot of time now to write up a sensible approach that uses the K1S1 look but I can check later. Maybe someone else can have some good advice in the meantime :slight_smile:

Okay I can think of two routes here. I hope they makes sense on a technical level as I’m also still learning :slight_smile: so anyone please correct me if it’s rubbish!

One makes use of a full ACES workflow and the other ditches the RRT+ODT in favor of ARRI LUTs. Both can use the ACES 1.2 OCIO config but the latter isn’t really an ACES workflow, I just used it for convenience of color space conversions. For the ARRI one I chose the ALF-2 LUTs (that’s what the others are right?) instead of K1S1 because the Classic is only available as Rec.709 from what I could see on their site.
The K1S1 ACES LMT is not something official but was created by @priikone more info here.
Pekka describes that it’s best to also use the RGC because the LMTs preserve high saturated colors.
The LUT based RGC I took from the StdX config that @Derek suggested in his post above.
This is a 1d shaper and cube LUT so can be used in our ACES 1.2 setup.
This ACES setup comes close to what K1S1 does except for very bright colored lights.

I do want to point out that regardless of what route you take, when it comes to lighting and rendering in Blender, it’s virtually pointless to do this with that ACES RRT+ODT I suggested earlier because you are modifying the look of ACES in Natron. Unless you create that same setup as a look in the filmic config you’ll get a different result anyway so maybe viewing with filmic is already sufficient. Maybe figure out for yourself what you find most sensible to do there.

ACES workflow
→ Blender render in .exr (sRGB/Linear)
→ Natron all media Read converts to working space (ACEScg)
→ Comp and grade linear operations
→ Convert: ACEScg to AWG/LogC
→ Comp and grade in log
→ Convert: AWG/LogC to ACES2065-1
→ LMT Reference Gamut Compress LUT based

  • aces_gm_lut_shaper_to_linear_v01.spi1d dir: inverse
  • aces_RGC_33.cube
  • aces_gm_lut_shaper_to_linear_v01.spi1d dir: forward

→ LMT Emulate K1S1

  • M-ARRI_Classic.clf

→ Convert: ACES2065-1 to ACEScg
→ ACES RRT+ODT to Rec.709 / P3D65
→ view /write

ARRI workflow
→ Blender render in .exr (sRGB/Linear)
→ Natron all media Read converts to working space (ARRI Wide Gamut / Linear)
→ Comp and grade linear operations
→ Convert to AWG/LogC
→ Comp and grade in log
→ ARRI LUTs to Rec.709 / P3D65
→ view / write

Here are the nodegraphs, hope it’s somewhat readable. The conversions after the read nodes are just for clarity, you could do this on the read node themselves ofcourse. If you’re interested I can also share the .ntp’s.


2 Likes

Let me just add this from the RGC User Guide which has this to say regarding LUT precision for 3D LUT implementations of the RGC

LUT Precision:
To achieve a reasonable approximation of the ACES RGC transform a 3D LUT implementation should use the highest practical resolution (e.g. 65x65x65) as well as tetrahedral interpolation.

With the above in mind, it would be better to use the higher-precision 65x65x65 LUT if used for writing, rather than the 33x33x33 one which I use solely for viewing. Here’s a link to that on my repo:

https://github.com/sharktacos/OpenColorIO-configs/blob/main/legacy-OCIOv1/studio/aces_RGC_65.cube

2 Likes