ACES metadata preservation

We are just about to start a new show, with just under 200 shots that is slated for Flame.
However, we have hit a major problem. The clients are insistent that the ACES metadata needs to be preserved.
Of course, this is impossible to do in Flame, this is a deal breaker for us and will mean some major reorganising of assets.
See attached jpeg to show what happens after round tripping through Flame to the metadata.

Can anyone on the dev team tell me if this is something that will be addressed in the future, (sooner rather than later)
I realise that it could be done in Nuke using copy metadata, so as a workaround, could I run Nuke on my Flame under python.

1 Like

We’re facing the same issue and have resorted to creating a delivery script for each shot in Nuke that adds burn-in, slates and jams in the original metadata. Only way to do it at the moment unless you want to get your hands dirty with some Python and have very strict organization/naming.

Yes. I hope a day flame will take care of the metadata.
So frustrating.


Yes, we’re getting more and more of this, its only going to get worse.

“Can anyone on the dev team tell me if this is something that will be addressed in the future,”
I guess that’s a no then.

the metadata preservation in the file and exposure via timeline burn-in are the real achilles heel of flame for anything longer than a 2 min commercial. @fredwarren @Slabrie

we are seeing a lot more episodic work in NY and sadly flame cannot join the party.


Hello Kyle, Franck, Paul & Tim!

Managing the various file format metadata throughout the entire journey in Flame Family products is sadly not an easy fix that could be provided fast. We totally understand that many pipelines need the data from camera original, transcoded or VFX studios and no worry we have this items on our todo list.

As you would imagine, there are a lot of use cases and gotcha (well, if we were to keep and provide data, you would expect that all your workflows would be covered, right? What about taking data from one node in batch and plug it to a Write File? What about Timewarps? What about resolution data from a scan that gets scaled down t fit a deliverables that need touch up somewhere else? And the list goes on and on).

Please make sure to add your use cases to the Flame Feedback above.{8FBADB72-C1B4-44AD-B55E-888E3FDC17E4}&uf={6C28EE5E-98AE-49B3-B409-5C3A1777AA5E}&a=v&t=1


Hi Stephane, I think first and foremost a simple copy metadata node, as in Nuke would help a great deal.
We have just lost a job destined for Flame because of this.
Now going into Nuke!!

totally understand your point @Slabrie - i don’t think anyone here (or at least MOST here :)) have the expectation of metadata surviving every possible node and process that can take place in flame. I’ve added this to the Autodesk feedback Gen improvement request:

ideally whatever metadata is included on the original clip would survive ingest into flame. After that it would be up to the artist to copy / apply the metadata on the final render a la Nuke. not unlike the T-tap we do in batch to copy timecode the to render node.

LMK if you need more info


Morning! Just so we can keep track of the conversation, I will continue the exchange on our Feature request page. Please get there so I can explain where we are at with this request.{8FBADB72-C1B4-44AD-B55E-888E3FDC17E4}&uf={6C28EE5E-98AE-49B3-B409-5C3A1777AA5E}&a=v&t=1#Newreply


hey Paul - are your clients also requiring a specific set of metadata to be in the burn-in for reviews / postings?

1 Like

Sounds like an easy Pybox integration, no?

It’s not for review, it’s the ACES metadata that they are insisting on being preserved.

Not really. Pybox could be used to strip the data in but the resulting frame gets passed back into flame where it would be stripped off again when exported. It would need to be written into a write node render hook to be preserved coming out of Flame and then delivered from that location—that’s to say, external to flame.