ACES open source software pipeline (blender, natron)

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:

2 Likes

Thank you very much Mr. Shebbe! That was really helpful! We appreciate the effort!

In this step: → Convert: ACEScg to AWG/LogC If I’m not mistaken you are using the “Input-ARRI-V3 LogC -(EI160) Wide Gamut” as Output Colorspace. Is it safe to use an Input aces ColorSpace as Output?

I have changed the aces_RGC_33.cube for the aces_RGC_65.cube (as suggested by Mr. Derek (Thanks mr.Derek!)

And I have also changed OCIODisplays nodes by OCIOColorSpace nodes (OCIODisplay nodes aren’t working for me properly - I think it’s a Natron problem)

I have been running some tests:

Blender Filmic

Blender Standard RGB

ACES+ARRI-Wide Gamut workflow

ARRI workflow

ACES v1.2 (NO ARRI) ACESv1d2_fromLiniarSRGB_toACEScg_toREC709

And the new Computer Graphics (CG) Config for ACES OpenColorIO 2 Configs for ACES

What’s your opinion?

I also attach my .ntp files and my .exr for if you want to check if I have been following your approach correctly.
https://drive.google.com/drive/folders/14GPLr-Q0EzANG0bkcTnrznuKLf3KmHJx?usp=sharing

Thank you very much!

If the ARRI colors isn’t important you could also test replacing the M-ARRI_Classic.clf with T-ARRI_Classic_Tone.clf, which just gives you the tone curve of the K1S1 LUT but colors will be ACES. It’s a lot simpler transform.

But there seems to be small difference in contrast between the ACES+ARRI emulation vs pure ARRI. I think that happens because you weren’t actually using K1S1 LUT but the ALF-2 LUT, at least based on the filename ARRI_LogC2Video_709_davinci3d_33.cube. I think the K1S1 is named ARRI_LogC2Video_Classic709_K1S1_davinci3d_33.cube.

The M-ARRI.clf would emulate the ALF-2 LUT, and T-ARRI_Tone.clf the ALF-2 tone-curve.

Thanks Pekka!

Using the T-ARRI_Classic_Tone.clf as suggested:

It seems to me the blue emission light shifts to purple and red one shifts to orange.

Here the ARRI-workflow using ARRI_LogC2Video_Classic709_K1S1_davinci3d_33.cube

For me K1S1 works better! Thank you!