Colourspace issues in Flame 2026/7

Flame Flame Questions
,
1

Hello,

I’m having issues getting consistent values for colourspace in a flame batch.

I have a project set up using ocio config 1.2 set in the OCIO variable. I have a PyWriteFileNode (which inherits from PyNode) linked to a read node. In the batch window the read node shows a colourspace of “acescg”. However, the new colour_space property doesn’t seem to work;

import flame
n = flame.batch.nodes[-2]
print(n.type, n.colour_space)
# 'Write File' None

If I use the workaround I implemented for <2026, I get the expected value;

import flame
from pathlib import Path
n = flame.batch.nodes[-2]
n.media_path_pattern = "<colour space>"
colour = Path(n.get_resolved_media_path(show_extension=False)).stem
print(colour)
# acescg

However, if I use a colour management node and transform the colourspace with ACES > ACES - ACEScc I get a different result;

print(colour)
# ACES_-_ACEScc

And then if I access the colourspace from metadata I get a different value again;

print(n.get_metadata()['autodeskColorSpace'])
# ACEScg

Which is not only in yet another format, but is now also incorrect, because in the previous step I set the colourspace to ACEScc, not ACEScg.

Metadata accuracy aside, these kinds of format changes make it really difiicult for pipeline to manage tooling.

2

I’m curious why you would not adopt aces 2.0 as a color policy since aces, aces cc and aces cg has not changed…

3

The colour_space property on Write File nodes seems to work for me. Are you sure it has something connected to its input? If so, perhaps you could work with support to help them reproduce the issue.

Regarding your ACEScc example, I’m not following what the issue is. You changed the colour space to ACEScc and that’s what is being reported, so it’s as expected right?

Regarding the “autodeskColorSpace” metadata, what you are doing there is getting the metadata that was in the header of the original file. It will be replaced if you write a new file, but it is not updated at every node through the Batch graph to track the colour_space property.

4

thanks for your responses, in answer;

@philm legacy pipeline tooling that is beyond my control

@doug-walker

  1. yes, otherwise the second example wouldn’t work. How have you set up your batch so that you got it giving a non-None result for PyWriteFileNode.colour_space?
  2. The format of the colourspace naming is different. One is all lowercase, another is ACES in upper and the rest in lower, the acescc example is prefixed with “ACES_-_”. In our pipeline we only allow EXRs to be published as ACEScg, for example. Which is difficult to manage when there is no standardised format for these namings.
  3. Yes, but this is incorrect. The exported file could be labeled as one colourspace but actually be in another.
5

Here is my response in reply to your questions, Ed:

  1. I didn’t do anything special to test it, I simply added a Write File to a Batch and then got a reference to the node by name in Python and printed its colour_space attribute. Perhaps somehow your node was not initialized before the value was extracted, or something like that, but as I wrote, you would need to work with support to help them reproduce it.
  2. Thanks for clarifying that you were referring to variations on the name string. As you may know, OCIO configs allow various synonyms or aliases. The names you shared are not coming from an Autodesk config, so they must be coming from your config. However, I would expect the name you see in menus in Flame would be the same name you get from the colour_space property in Python. If you find that’s not the case, that would be another situation where it would be best to open a support case with an example config.
  3. I’m not sure why you feel it’s incorrect. As mentioned in the documentation, the autodeskColorSpace gets replaced when the file is written with the current value. In other words, it’s not just repeating the value from the source file.
6

@ed-spencer, a colleague figured out why trying to get the colour_space on the Batch node was not working for you. This should be fixed in a future update, apologies for the issue.

Hopefully that will allow you to not have to rely on your workaround since the string used for the media_path_pattern gets modified to replace characters not suitable for use in a file path and therefore won’t necessarily match the actual color space name.