Baselight works fine. Nuke doesn’t.
I wanted to get the nuke system working because the tk ops are getting busy. And grumpy doing these little exports for me. If only flame didn’t strip the metadata.
Hi, bumping this thread up to see if there have been any developments. We’d really love to see the preservation of any metadata possible in EXR exports. For one, so that TC, tape name, etc. can be preserved for pipeline reasons, and two, so that artists can see the camera, resolution, etc. for a given shot in both Flame and Nuke without having to track down the camera RAW source clip. @Slabrie are there any developments on this front yet or a planned feature update? Thank you!
Hello Lee!
Preserving OpenEXR metadata is high on our list of requests and we will let you know when this capability is added to our products.
Which version of Flame do you use?
For timecode and reel/tape name, it is already possible to export content with this data in OpenEXR for the following workflows (using 2023 release and previous)
-Media Export (File sequence): exporting single source clips will preserve source timecode and reel/tape name in both Forground and Background.
-Media Export (Publish): if you are jot using Flatten Track option, you are able to export segments of your sequence as OpenEXR with source timecode and reelname
-Bach (Write File) make sure to use T-click to propagate the data (timecode and reelname) from your back plate to the Write File node set to OpenEXF format.
As far as viewing the OpenEXR metadata, we provide the ability to view the metadata of the first frame in various ara of Flame Family products:
-MediaHub (Preview / Metadata and if you expand the Attributes section you will see the various information part of the header)
-Batch (Clip Node / Extended / Metadata)
-Timeline / Format Options / Metadata / Attibutes
being able to display the metadata on a frame basis is on our todo list.
As you have seen, we sadly do not preserve nor export this data when exporting OpenEXR and we fully understand the various workflows that would enable.
2 Likes
hi @Slabrie curious if you have seen this solution posted by Dan here and wondering if there is any change or difference in image quality when going this route:
Hello Tim!
We are talking here about a very old workflow called Publish Link which provides the ability to export media to the same file system as the source media and try to create file system hard links to avoid duplicating media. This capability enabled a lot of Flame long form finishing workflows many moons ago. It was used with DPX source at the beginning of the DI era and made its way to Scene Linear / ACES workflow with OpenEXR.
If you publish sources and there is no FX and that the resolution, bit depth, compression matches the source file AND that the destination is on the same file system then
resulting files will not be new media but hardlink, pointing to the original files and then you will have access to the full metadata.
If you modify any export parameters breaking the hard link mecanism then we will generate new media and no metadata will be available.
1 Like
Hi Stephane -
Is it possible to get this data in thru json?
ARRI metadata can get extraced this way I thought…
Also write out thru json too?
Thx in advance.
Andy D. (westside)
The metadata of the original media sadly does not make its way in Flame so it cannot be formatted in XML, JSON or any other format from within our applications. But we have this on our radar, as we stated many moons ago. There is sadly not enough 48 hours in a day 
2 Likes
every arri prores job…
Resolve to get all the prores metadata into a exr (i also just blaket denoise here …)
Nukestudio to publish them into shotfolders
then flame , comp…
Copy metadata in nuke write out deliverable.
yay.
1 Like
I’m not understanding this workflow… if you are conforming, assigning shot #'s in NukeStudio then why are you going into flame?
depends on the talent i have in the studio and what we need to do.
Most often its the other way around
resolve->ns->flame(timeline)
depends but if we deliver shots yo certain clients they expect metadata to be there so ive written some automation to inject it unsing nuke,
Before we had dasgrain in flane I often did it with dasgrain as well,
1 Like
Err… I just can’t believe what I am reading… Flame not passing the metadata on exports? all the camera lens information, roll, tilt, etc…gone?? REALLY?
Holy cow, this is a total disaster, this needs to be fixed ASAP!!
2 Likes
@jordibares - yep, that asap has not been as soon as possible for many people for many years.
Welcome to the party.
I think there is a feature request.
If not, make one.
Happy Saturday brother.
basically makes it entirely impossible to use flame in high end environments without pipeline tooling to inject the metadata back with nuke or something
tbh if you need to work on heavy shots and actually use that metadata to drive a camera defocus or something you wont be starting flame even … nuke runs circles around flame for these complex things all day long not even the same playground
4 Likes
@finnjaeger - flame is also used in the most high of high end productions where pixel fucking to the nth degree is done in different ways.
Torture is not a singular path.
Matching grain (cough) to source digital cameras is a barrier to entry invented by a bunch of dipshits who have long since been consigned to the dustbin of history.
Pan tilt roll focus altitude are meaningless if you have a good lidar/match moving/ reconstruction/retopology team.
Nuke cannot keep up in this environment.
It is the sole domain of flame.
its not just tilt roll, its lens info, comments all kinda of other stuff you can save in there
ive gotten so many metadata issues that where flagged by the largest clients … bascially excluding flame from any kind of viable pipeline path right of the bat
yes they will pixelfck your grain but they also want specific metadata…
1 Like
@finnjaeger - yep you’re right - undoubtedly
But the biggest and most successful pipelines for finishing on earth are flame centric.
2 Likes
I’m not going to say I don’t want the metadata, as I totally do because it makes a lot of things a whole lot easier. I also agree with @philm that with a good matchmove artist/team that the metadata is less important.
One thing to also keep in mind. I’ve lost track of the amount of times I’ve been given a bum steer as the camera department has used vintage lenses or lenses that don’t automatically transfer the lens data to the camera body and they’ve manually entered metadata that is actually wrong. It’s easy to blame the professionalism of the crew but when a shoot is time pressed or they have a mix of lenses that can or can’t transfer metadata, it is an easy problem to have occur.
1 Like
Regardless of the situation with flame over the years, we should recognise a first-class tool, if not THE tool that is the gold standard should be able to pass the metadata, I mean, it is surreal we even try to justify it.
And it is not just pan/tilt/focal length information, is the ability to organise quickly large volumes of material, is the ability to attach lens serial numbers and with it, lens grids with them, is the ability to do automatic footage undistortion so no, this is not acceptable, sorry.
Autodesk, you guys need to wake up and get this right, we can’t live without metadata and it is only going to be more important so please please please do it.
5 Likes