New Color Management in 2026

[kily]

Hi everyone.

I have been able to briefly test the new version 2026.1 (I’m coming from 2025) over the last few days and I’m confused with the new color management. Specifically with view transforms.

I’m testin with several footages and color spaces, in a test project set up as ocio2.0 .

Within view transform menu popup, now there are two news popup menus: “View transform” and “colour spaces”. And with sort of duplicated sections: input, utility, aces…

If I setup a new view rule, for arrilogC3, or RedWG footage, from “view transforms” (all transforms are named as “curved”) for arri or red footage, I get a weird look with magent faces aspect. If I setup same view rules from “Colour spaces” popup menu , nothing happens. The footage is rightly tagged, sure.

Same with several scenarios more. with sRGB linear 3D renders, the view rule setup with colour spaces>utility>Linear>Linear Rec709(sRGB) again, nothing happens.

In short, view rules from “view tranform” popup works doing weird thing, and I don’t know WTH is “curve”. View rules from colour spaces do nothing in the mentioned examples.

I suppose it’s something that’s very obvious and very simple, but I just don’t see it.

Also, I’m a little confused about the new role of the “color transform” section within the Color Management node. Before, it worked like a transform “from A to B” based on the long list of transforms “from A to B”, like “LogC to HD video”. Now, it only shows profiles such as “Arri Logc4” Am I to assume, then, that it implicitly transforms from the fedded image source tag to the selected target? Something like the “from source” of the input transform. So basically, now, works like the input transform but with a more extensive set of transforms, right?

Thanks.

[PlaceYourBetts]

Hi @kily

From what I can tell, using the ACES 2.0 ocio config will give you all of those Colour Spaces and Input Transforms but Flame also does a merge with it’s own ocio config. This is to help Flame become more of a swiss army knife DCC and deal with additional camera formats not included in your ocio. Although ACES 2.0 is extensive and pretty much has you covered not all ocio’s are quite as thorough.

This might be where some of the apparent doubling up is coming from although you might find that ACES 2.0 ocio config appears to have some duplicates given that some View Transforms and Colour Spaces are very similarly named.

Colour Transform has changed from how it used to work and I was initially thrown by the change. It feels less of a scratch pad for experimenting and more of a way to get into the ocio under the hood. Most of my dabbling now happens directly on the ocio config itself. We have a custom config for our office and it is very paired back and simple.

It was an abrupt change in concept for me but you have two choices, you can roll back to the legacy syncolor CTF and work the way you are used to. Or you can struggle for a little bit and figure out how the OCIO is doing it’s thing. OCIO is industry standard and well worth the adventure.

[PlaceYourBetts]

What I liked about SynColor was the amount of options I had available in custom mode, laid out in seemingly convenient sections.

_{As i write this i am reminded at how initially I was very confused by the custom mode}

I could adjust my primaries, convert my white point, change my display transform.

It appeared that everything was available to me. I would often experiment and try different conversions until I was happy with my results.

Now with OCIO it seems that if it isn’t explicitly written into your config then you can’t do that.

I started Flame 2026 using the default ACES 2 OCIO config and was initially very confused and disoriented with the way that the colour management node now operates. This says more about my lack of experience with colour science and OCIO than the system itself but I do miss the old SynColor. The previous options you used to get in Type, camera, primaries etc. are now replaced with colour spaces and view transforms.

We must move forward and now that I am getting stuck into writing the config files myself, I am getting a much clearer understanding.

You can take a look at the config files and see what they are doing. The code, YAML, is very human readable although I would add that the ACES 2.0 config is extensive.

/opt/Autodesk/colour_mgmt/configs

Have a look here at this demo config. It has heaps of comments and helps explain things:

ocio-v2_demo

[PlaceYourBetts]

@kily

weird look with magent faces aspect

This is probably converting the arrilog into the interchange colour space. Sounds like CIE_XYZ_D65.

One of the basic concepts of the OCIO is to take every colour space and convert it into your interchange colour space. Everything goes into this space and from this space everything comes back out from and into what you need, whether that is a display device or another colour space.

[kily]

Don’t get me wrong. I’m very happy getting OCIO in flame. Although I saw Syncolor as cryptic and lacking of a clear nomenclature or info, I had also found my rules and I was comfortable with them.

I’m just confused.

It started with “hey, this isn’t working, hahaha, I’ll take a look, ” and a few hours later, I still couldn’t get a simple view rule to display for example, arrilogCv3 footage.

@PlaceYourBetts

One of the basic concepts of the OCIO is to take every colour space and convert it into your interchange colour space. Everything goes into this space and from this space everything comes back out from and into what you need, whether that is a display device or another colour space

Okay. This has been enlightening for me. So, as I understand it, implicitly, view rules now convert everything to ACES, so all I really need is one ACES view rule (typicaly, ACES SDR 100 nits for rec709), right?

This agrees that the only (apparently) right way to display Arri or Red footage I found was precisely by using the aces view rule. What didn’t make sense to me.

[PlaceYourBetts]

This doesn’t mean you can’t use other view transforms.

If you prefer the K1S1 Arri view transform (now named ALEXA Classic 709) to the ACES 2.0, you can make a colourspace for this view. Since this LUT expects LogC3 material I need to convert from our interchange (ACES2065-1) into our camera log (ARRI_LogC3) and then apply the LUT. So my colour space (view transform) looks like this:

  - !<ColorSpace>
    name: ARRI K1S1
    family: Displays
    equalitygroup: ""
    bitdepth: 32f
    description: Arri Classic 709
    from_scene_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: ACES2065-1, dst: ARRI_LogC3}
        - !<FileTransform> {src: ARRI_LogC3-to-Gamma24_Rec709_D65-Classic_33.cube, interpolation: tetrahedral}

ACES2065-1 andARRI_LogC3 are two other colour spaces that still need to exist in your config somewhere

[kily]

I think I’m gonna need more than 5 minutes …

[doug-walker]

@kily , if you want to add an ARRI K1S1 LUT, you may do that from the Flame UI, you don’t need to be editing YAML code in a config file. This is documented in the user manual.

Your questions above are so open-ended, it’s hard to know how to help without typing out the whole user manual here. If you have questions about anything in the documentation, I’d be happy to help.

[PlaceYourBetts]

Sorry @kily

I have clearly over complicated things by talking about the underlying code

I bounced off the ACES 2.0 config because it was so vast and moved to our simplified, company config, which I need to maintain by updating the code.

[kily]

No!. Your answer gave me the clues to start to play around this new stuff. I knew about adding a custom lut, thanks @doug-walker . Now I prefer to dig into this stuff and create a custom ocio config.