Hello everyone. Long time listener, first-time caller here.

I’ve graded Resolve ACES for several years, so I’m comfortable with the grading workflow, but I’m having trouble creating a viewing LUT to send to our 3D department for use in C4D/Redshift.

When sending ACEScct LUTs to VFX for use in After Effects and NUKE we apply a couple of different CSTs to get the ACEScct LUT processing in the right space, like this.

Basically, it involves converting from ACEScg to ACEScct, applying the LUT, and then converting back from cct to cg. Unfortunately, there are no such CSTs in C4D.

Is there a method to convert ACEScct LUT to ACEScg?

Hi Chris,

I’m not crazy familiar with C4D/Redshift but I do know that they can use the ACES ocio configs for color management. I don’t think it’s possible to load a LUT outside of that system or can you?

What the construct would be is that you’d add the LUT to the config itself which you can do in various ways. The most logical would be to add it as a Look. However I’m not sure if Redshift supports Looks as selectable options like you can in Blender. If you can’t you’d have to also add a new view transform that is for example sRGB Display + the look.

Regardles of the setup, you don’t have to convert the LUT itself to ACEScg, it’s process space can remain in ACEScct.

@Derek has some customized setups that are well documented, perhaps they’re useful to you.

C4D and Redshift both support OCIO CM when bringing in footage and textures - bringing in an ACEScg plate to use as background is a breeze. Unfortunately, there’s nothing like that when it comes to applying LUTs.

Here’s what I get to work with.


I’ve just tested out a random rec709 LUT and this works when the ‘Apply color management before LUT’ button is ticked as one would expect.

Not ideal as I would prefer for the LUT to be working within the ACES colour space but it could be a workaround and this only for previewing after all.

The next question would be does anyone know how to convert a LUT from ACEScct to rec709?

Again, simple enough to make it work within Resolve, AE, NUKE etc by sandwiching it within a couple of CSTs but I don’t know how to get the LUT out working in this way.

It looks like that place for applying a LUT is from the workflows before OCIO support was in place. The checkbox Convert to log space before applying LUT doesn’t have any clear documentation as to what it exactly does so it’s probably not suitable for use in conjunction with OCIO.

So it comes down to implementing the LUT as a Look inside the OCIO config that is being used by them. Are they using the built-in ACES config from Redshift? We also have Redshift here, I could mockup an example config that would accomodate an extra LUT for a look.

I wouldn’t recommend this as you will be much more limited in manipulating the image over a scene-referred grade LUT.

Yeah, they just using default Redshift settings.

I love colouring in ACES, but after 10 years of it being around, I still can’t believe there isn’t a simple solution to this. Colourists work in ACEScct, and VFX artists work in ACEScg. By now, there should be a very simple and well-documented solution for providing a simple viewing LUT to VFX from grades created in the cct colourspace. Before, when everything was 709, everything was 709. Sometimes ACES feels like a step backwards.

I understand your sentiment but even back then it wasn’t as simple as that. Cameras already captured in wide gamuts and often managing color with CG and digital cameras was actually largely mismanaged and eyeballed because nobody really had a solid grip or appropriate tools to handle it.

As to current implementations, it’s not limited to ACES, it’s mostly OCIO that takes a bit of learning to understand how it is utilised and implemented in various software. It’s an incredible flexible system but not all apps utilize all of it’s features to the full potential. This causes some manual customization for some artists/teams to suit the needs for their projects. The good thing is that it is actually highly customizable but the learning curve can be a bit of a hurdle. :slight_smile:

So here is a modified version of the Redshift config to use with a LUT.
What you need to add yourself is a folder next to the config named luts and place your ACEScct based LUT there with the name showLUT.cube or rename it to whatever you want it to be and also change that name inside the modified config file.

The lines that I changed/added in the config are:

search_path: "luts"

to add the folder luts to the search locations for using external files inside the ocio config.

Under shared views:

  - !<View> {name: ACES 1.0 SDR-video + showLUT, view_transform: ACES 1.0 SDR-video, display_colorspace: <USE_DISPLAY_NAME>, look: showLUT}

to add a new view transform that includes the newly added Look

Under displays:

    - !<Views> [ ACES 1.0 SDR-video, ACES 1.0 SDR-video + showLUT, Un-tone-mapped, Log, Raw ]

Added the name of that new view with LUT so it can be seen when sRGB is picked as the display.

And the definition of the look itself named showLUT all the way at the bottom under looks:

  - !<Look>
    name: showLUT
    process_space: ACEScct
    transform: !<FileTransform> {src: showLUT.cube, interpolation: tetrahedral}

You can see that the process space is ACEScct. This causes the config to convert to that space before applying the defined transformations and back to it’s reference space once the transforms are applied so it’s similar to that manual sandwich you showed in AFX.

Hope this helps!

1 Like

Thank you, Shebbe. This is next-level work, and I really appreciate you taking the time to look at it.

I have one more quick question - Is there any way to view in rec709 as opposed to sRGB? My monitors are set to rec709 to get as close match to my external monitor as possible, but with OCIO display set to sRGB things look more crushed than they should with the gamma mismatch.

Glad it helped,
You may prefer leaving the View in the global CM settings to just ACES 1.0 SDR Video and swtich the Redshift Viewer to the one with LUT so it isn’t enabled by default. Whatever works for you.

It is a bit weird that Maxon/RS didn’t bother implementing other displays. They may have done so to prevent confusion but it doesn’t help much. You could add the Rec.709 - Display yourself by grabbing it from the ACES released OCIO configs (the 1.3 Studio config available in After Effects for example).

You need to add the display in the displays list (just duplicate the sRGB one including it’s views and rename to the new display). Add it as an active display. And define the display in the display_colorspaces.

I encourage you to try it yourself, the ACES Studio config can serve as reference, if you can’t get it to work happy to help.

Hello Shebbe, this is excellent!

Would it possible to do the same with a LogC v3 to Rec709 LUT, instead of an ACEScct to Rec709 LUT?

The Studio OCIO config comes with built-in transforms for ARRI LogC3 and LogC4. What these do, and what all input transforms do, is convert from the color space of the media (for example LogC3) into the ACES working color space. In an OCIO config that would be AP0. In Nuke that would be AP1. The idea is that you want to bring all the different source media into a unified wide gamut working color space. In the case of color grading that is typically a log space. In the case of rendering that is always a scene linear color space.

With all that in mind, it would be helpful if you could say a bit more about what you are trying to accomplish with a LogC v3 to Rec709 LUT. FWIW, OCIO v2 does not actually use LUTs at all, but instead has analytical transforms, which are more precise.

Some of the artists have requested the ability to preview the show LUTs (which are provided by clients and thus we have no control over) inside of RedShift and C4D directly, instead of only in composite. The artists are working in ACEScg already, but their previews are the standard ACES 1.0 SDR view, not the actual one that they should be seeing.

We’ve had this functionality given to us before, but only when the facility was able and willing to produce and share their own custom OCIO config (which is uncommon). I’d love to see if it was possible to create such a customization on our end based on the workflow that Shebbe described.

Thanks, a couple more questions:

  1. Is the footage in AP0 EXR or can it also be DPX log? If the latter do you know the log space so you can convert it to ACEScg in Nuke?

  2. Is the show look in an ACES pipeline (meaning it is an LMT applied before the ACES output transform) or is it completely replacing the ACES ODT? I would guess that it can be both, but you need a different appeach for each so its important to know what you’ve got.

For (1) I’m not really familiar with C4D, but I can say that for Maya Arnold you need to convert footage into ACEScg EXR files for them appear correctly in BG of the Render View. I would imagine that Redshift is the same. So you’ll need to convert these in Nuke, either from AP0 into ACEScg or from whatever log space the DPX files are in to ACEScg EXR.

have a look at the following doc:

In particular the section " Shot & Show LUT Config & contextual variables."
Here I have the two scenarios I mentioned above:

VFX - ACES Shot Look (Rec.1886 Rec.709 - Display) which assumes the LUT was made in an ACES scene-referred workflow in ACEScct working space (the log color space used for color corrections).

VFX - DPX Shot Look (Non-color managed DPX workflow) for displaying client LUTS from a display-referred non-color managed pipeline. This is typically the case with DPX footage, although a show can have a display-referred pipeline and use EXR files. The key issue is whether the target display EOTF (for example Rec.709) was baked into the LUT, making it display-referred. Here the camera native color space needs to be defined as well as the process space the LUT was generated in.

Both use contextual variables to apply the show or shot-specific look LUT provided by the client to the view. These are defined in the following section at the top of the config file.

# ---------------- Per Shot Grade Variables ------------------------- #
# example path: ../shots/SM_020_018/01_Client_Original_Footage/5_LUT/
  LUT_PATH: shot_lut/
  LUT_NAME: clientShotLUTname_ACEScct.cube
# Camera aliases are: ARRIv3_log, ARRIv3_lin, ARRIv4_log, ARRIv4_log
# RED_log, RED_lin, CLog2, CLog3, Panasonic_log, Panasonic_lin, ADX10
# Sony_log, SonyCine_log, SonyVenice_log, SonyVeniceCine_log, Sony_lin, SonyCine_lin, SonyVenice_lin, SonyVeniceCine_lin, 
# CAMERA variable is set to ACEScct for ACES EXR workflow, and to camera for DPX for display-referred workflow
  CAMERA: ARRIv3_log
# ------------------------------------------------------------------- # 

You would replace the LUT_PATH and LUT_NAME with the correct names for your environment. if the client is delivering a LUT for display-referred footage, the color space of the original camera should be entered into the CAMERA variable to set the log space for the Shot Look (Non-color managed DPX workflow) display transform. See the above doc for more details.

Here’s the OCIO config with all of this stuff in it:

You’ll want the StdX_shotLut.ocio

Once the config is setup with the Show LUTs, the artist just needs to choose the appropriate View Transform.


1. In this case, there is no footage involved.

While we are working in a larger pipeline that will include footage, our sections are typically 100% computer generated (Like a title sequence for a TV show or a studio logo). If there is any real footage involved, we only deal with it in After Effects where we can do more robust color management. However, you can tag imported files in cinema without having to pre-convert them. C4D has implemented a reasonable OCIO system under the hood.

2. In most cases the look is replacing the ACES ODT.

For some additional context, out of the roughly 50 -80 projects we’ve done in the last 4 years (hard to accurately keep count, lol), we’ve received 1 LMT, 2 standard ACES requests, 4 OCIO configs (2 were ACES based and 2 were not) and the rest have been Rec709 LUTs based on camera log spaces. The traditional LUT system is the VAST majority of show pipelines we encounter, even if they are working with ACES.

Thanks again.

That would be the display-referred non-color managed pipeline I mentioned above. It’s display-referred because the Rec.709 EOTF is baked into the LUT. Since you are only using the LUT for viewing purposes in OCIO, that should be fine.

1 Like