ACES 2065 tagging

Apologies if this has been discussed before, but we are experiencing something odd in Flame and in Nuke.
Scans are coming in correctly tagged as 2065, however, when we export from Flame and pull into Nuke, it tags it as ACES cg and not 2065.
The same thing happens the other way, ie exporting from Nuke and pulling into Flame, again, the file header says ACES cg not 2065.

Apps don’t know what something is. You have to tell it. Be explicit within your tagging and you’ll be fine.

Everything is being tagged correctly as 2065, but this is not what appears on import.
As I said, it’s happening in Nuke and Flame, the only workaround in Nuke is to carry over the metadata from the scan, but as far as I know, this is not an option in Flame.

Yep. Metadata node in Nuke will solve your woes there but flame write nodes don’t support color space tagging as insane as that sounds. An export should tag it correctly though I believe.

1 Like

probably, because flame can not read the proper tag from metadata, it will follow the rule, from your color policy, .exr tag as aces cg. So you will probablly have to be aware and switch it manually or change the input rule in color management settings.
same thing in nuke.

Just so you’re aware @saul unless you explicitly use the copy metadata node before your write in Nuke you won’t retain any of the useful tidbits from the original file. Setting the read node colorspaces is crucial of course but that won’t follow through to a write unless you explicitly copy it over or write it in. There is one exception though. If you enable the write node option of “create an aces compliant exr” it will tag the write nodes exrs as 2065. It would great if Flame’s write nodes would adhere to the colorspaces being written—it seems like a glaring omission.

To your broader point, if @paul_round is importing the files from wherever with an import rule that blindly tags exrs as, say acesCG, which is what the default aces workflow does, all exrs will be tagged as such and will be wrong. In that case it would be to change the import settings.

totally. I got you.

Just following up on this.
We have a new show in where they have explicitly said the ACES metadata needs to be preserved, however, doing a pipeline test in Flame, (which is where the show is slated to happen), does not carry through any of the ACES metadata.
This could be a deal breaker for us if theres no way around this.