Hi,
Does anyone know how to maintain important camera information from LDS lens’ such a focal lengths, which is kept in the meta data, but stripped when you export out of flame?
I know flame doesn’t display these tabs but is there a ‘copy source meta data plugin’ out there so that its kept anyway?
Thanks
Alex
There is a plugin. I think it’s called Nuke? 
Do we have a feature request for this already that we can all vote for? I’ve had this problem for years. Especially annoying if Flame doesn’t keep the timecode that Baselight is using. We had to run all shots though Nuke on one job just to insert metadata before grading. 
To answer my own question: Let’s all vote here:
https://feedback.autodesk.com/project/feedback/view.html?cap=5afe6c845cb3447ab36ccbd7f0688f84&uf=6c28ee5e98ae49b3b4095c3a1777aa5e
we use baselight for all in house color jobs, we never had this problem unless the artist did not use the ‘make batchgroup’ from timeline or T-tap the batch render node from the source clip (which forces the TC; shot name; etc to be transferred to the render. Apologies if i’m not understanding all the details of your situation @claussteinmassl. That being said, overall this is a tremendous headache and one of a few glaring Achille’s heels of Flame vs Nuke. Its pretty clear data collection at acquisition is increasingly crucial and will most likely ballon over the next few years. I don’t think it’s a matter of desire or awareness on ADSK side, the feature request is years old. Maybe it’s a fundamental lack of infrastructure at the clip level which would require a major overhaul… Maybe @fredwarren @La_Flame @Slabrie can illuminate us…
@TimC This case happened two or three years ago, so I don’t remember all details:
The plates (I think it was Alexa) contained three different timecodes in the metadata. I conformed the edit in Flame, did a sequence publish for the Nuke Artists and all those exported plates hat only one of those timecodes left. Unfortunately it was not the one, that Baselight needed to conform the Nuke Renders again. So we had to do a copy-metadata in Nuke from all original plates on each render, that we did.
It looks, like Flame is only keeping the bare minimum of metadata. I would be super nice, if it just kept all metadata and eventually let’s us even add custom metadata. This could enhance pipeline scripting a lot! @FriendsFromAutodesk please make this happen! 
No worry we get it. It is sadly not as simple as it might seem and would require lot of changes. But this is still in our big list of things to add to Flame Family products.
hi @Slabrie !!! thanks for the quick reply… i cannot help but wonder if there is an interim solution, some sidecar application or plugin that can copy the meta data from the original clip on our server to the export or something like that so we can still (sort of) stay inside flame…
anyways hope you and the team are all doing well and looking forward to knocking out all the items on the ‘big list’
Yes this would be ideal to have an interim solution.
We are increasingly taking on jobs which need this and its vital to be able to spit out all the extra meta data (mainly camera meta data) with our conformed edits.
I do not see simple interim solutions sadly. Maybe some of your who played with Python scripting could re-write file metadata BUT that could be very messy… I would not recommend that.
We have automation to “re-run” the export thru Nuke to re-insert the original metadata back in. Fun fun.
@Slabrie Paul Crisp solved this at the mill by making a Python script which would look at a timeline and copy the source media from rushes server to shots server and then rename it as per the confirmed shots.
Are there any scenarios where you need to have all the meta data on a render? I can only think it’s necessary on a source plate for the cg dept.
Yes its pretty much this example for Cg to use. All the meta data is a bit overkill and there is a lot of useless information. It would be great if you could customize or choose what you want to be kept.
The nuke automation seems like a possible good option for an interim solution unless we can get hold of this python!
In the case where you publish source media using the same format & encoder as the original media on the same file system* (i.e. as an example OpenEXR PIX sources) then you could use the Link Media option and this will solve the issue. But there are a lot if use cases where one would want to get the source file metadata like using RAW camera format (i.e. ARRI, RED, etc) and then publish as OpenEXR. There are also the cases where the metadata should be edited or updated,etc. All in all, not a simple thing to do as I wrote.
*It is also possible to enable the Soft Link option if you want to publish to another file system on the network (located in Stone+Wire.cfg file, look for SymLinkAccrossFileSystem option, which if disabled by default). Should be used with caution since Soft Link are quite volatile if you move or delete original media files…
So I managed to get it all working by reconforming in Nuke (the hiero part whatever it’s called). Exporting all seems to work fine too.
One thing that seemd a bit annoying:
The edl exported from connected conform flame with nice shot names comes into nuke with blank names.
Does anyone know what I can do to fix that?
Did you export an EDL or AAF? I’ve reported issues with exporting AAFs and it not carrying through renamed clips (i.e. someproject_0010).
It was an edl. Very odd. I could see all the data clearly in text edit and it worked perfectly in baselight. But in Nuke all the clips were un-named.
I’ve done done further tests. AAF doesn’t work as you rightly say.
EDL drag and drop also doesn’t work and all fields are blank. But if you export edl 3600 the old fashioned way the clips are named correctly and everything links up.
That’s weird I use EDL export for sending a conform to baselight all the time. This works fine is you only have 1 video track. If you have multiple, make sure selector thingy in your sequence is parked on the right track AND Use Top video track is disabled when exporting. OR use the old EDL module indeed 
