Hi there,
We tried to export the cached (to batch shelve) multichannel clip to a multichannel exr 32bits and reimport, to use instead of the cached (managed media) original, but when we drag and drop it on the MV node in action, we get a Warning Message saying "Not a MotionVector clip.
Anyone knows if it’s possible to export/import and use? something we could change in the header or other metadata?
I wonder if you just need to tag it as Motion Data. I’m not in front of it now but I’ll try this tomorrow.
Update: Misunderstood the use case, doing some further digging…
Yes, it’s possible. A few steps involved.
1) Write as multi-layer 32fp EXR file.
3) Create a new action, create one media input. Connect both channels to front and matte of that media input
4) Add a motion vector map in action, assign it to that media input
5) In MV change ‘Analysis’ to ‘Forward/Backward’ which activates the media input
Learning channel video: https://www.youtube.com/watch?v=fKsLuP9sdno&list=PLqfk4mdQn0sUtejFX-YPjBFvl8iEuxOi8&index=66 (which does not reference export, but just inside batch)
or archive.
Thanks @allklier. That’s not the workflow I’m talking about though.
I’m talking about the CACHE motionvector that flame puts in a batch shelve, which is a multichannel clip (8, 10 …). The one you can drag and drop onto the MV surface node in action, avoiding the need for constant secondary re-caching. I’m not in front of a flame atm, but I’ll try to post screengrabs tomorrow.
Btw, this wouldn’t work with openclip since it’s a multichannel clip.
My understanding is that this is actual some type of proprietary image format that is masquerading as a multi-channel EXR, but isn’t really.
@ALan is correct. The Motion Vectors are not your basic Motion Vector pass you can render out in 32bit
My understanding(which may not be precisely accurate), is that each frame holds data for that frame all the way forward and all the backwards.
So this is also the reason why these Motion Vector cache files are so large.
So yes, seems like archiving the cached vectors in order to share in this scenario would be an option instead.
Yes, I was digging deeper this morning having a second look after falling short last night.
What sets MV data apart from like a UV map which just maps source to destination pixel, is that MV data also contain direction and velocity and do so for both directions, which is why there are so many channels.
A motion vectors map represents the position, velocity and acceleration of objects in a scene. (Source)
Exporting the cached data in a 12 channel EXR file (manually or via the export function) seem to work, and you can also bring that back in, but it’s not recognized as such (which was Stephan’s original question). When you look at the differences in meta data they match on all fronts (color space, etc. etc.) with one exception. Alt-Click in the media panel will show an ‘H’ for the known cached files and ‘EXR’ for the imported file. No documentation exists what ‘H’ stands for.
It seems conceivable that these should be able to export and import. After all, archive does it. But my guess is that there is one meta data flag that identifies them as being generated MV data by Flame. Probably mostly so that you don’t throw a random EXR file at action with unpredictable results or crashes. Flame would have to include some sort of validation that the EXR file matches in channel count and data ranges to what works for the MV Map.
Seems like an appropriate feature request to make.
Wow thanks for digging deeper and fully investing/testing.
Interesting that it seems one can actually export these passes as such. Perhaps if there where just an added option in the Motion Vectors to either load from the chached Vectors as we can do now or select a rendered 12channel version.
I think this would be great for trimming down archive sizes even more by being able to compress the EXR Motion Vector file.
Yep, that’s basically why I was asking if there was something we could change in the header/metadata …
[H] is the tag for History, but the history view in timeline doesn’t show anything special
By the way, big thanks to @AdamF for bringing that up in the first place.
Check the enhancement request. Someone commented on it that it apparently is already feasible. Details coming soon. Looking forward to seeing it.
Additional tidbit from there is that the channel count isn’t static.
But when you export it via Meta-E from the media panel, and select multi-channel it will automatically use all of them, so I guess it would adapt at least on the output.
In my test this morning I’ve seen both 12 and 14 channels.