Your other salient technical points notwithstanding, we’ve all become accustomed to your prophecies of Flame’s imminent doom — for about 30 years now, going back to flame-news in the 90’s. I’ve had and still have similar concerns — but it’s kind of the boy who cried wolf at this point.
Here are my 2c:
Archiving as a concept needs to be sunsetted.
just let me export my timelines as files somewhere, thats all, thanks.
If only there was a way to export timelines via OTIO…
like FU_otio_export or something
Err, no. Not everyone works with timelines only
If you’re only doing shot work arching is a breeze. It editorial that forced everything into the uncompressed shit show it is now.
I think Timelines and Motion Vectors are really the only thing in an archive that can’t be saved outside of Flame right now.
What’s useful about a Publish workflow is you can collaborate easily with other artists, producers and clients because the media exists in its source format and legible by anyone. But I would take the idea of a 10mb archive with a grain of salt, the entire job folder is what you need to consider saving. And even though it’s not encapsulated in a .archive container, you probably should keep it. However, you can follow @Randy’s advice really well by sending OCN back to your client and not saving it because you have what you need in the original shot publish. You also probably don’t need to save intermediate versions of renders unless they’re referenced in the creation of the approved version. @randy is dealing gospel.
But… the upside of a cached archive is it’s all there. In the format you used it. No need to worry or think about it. If there is a potential for some producer’s nephew to get on your network and start moving material around within a job after it’s been delivered - it can make that whole project difficult to recreate.
But for cached archives… and this is a big caveat: you need to allot time to create that archive and you need just as much time to restore it. And… you need a Flame to read it. Cached archives get very big and they can eat up a good portion of a billable day with I/O.
There are defensible reasons for both ways of working and each has compromises.
OCIO, OIIO, OTIO is the future.
You need an exporter for OTIO, and you need to manage your unmanaged media.
That’s it.
If your workflow includes predictable schema and contents then you can do metadata only archives as well.
You can work towards sensible and comprehensive business continuity and lifecycle management policies or you can do brittle stuff that frequently breaks.
…and usd.
It’s been mentioned before but it’s worth noting that if you compress your cached Flame archives the size will be a fraction of what it was originally. Of course this takes both significant time to compress/decompress plus additional space.
Hey Kyle. This is definitely true for many cases, and makes sharing archives online less painful.
But in my opinion, the archive files should not have to be this big, if the user chooses to archive at the codec ingested. It’s a real waste of online storage costs, bandwidth costs, and a good bit of time as you have to wait for zipping and unzipping.
I’m still hoping to hear the ADSK rationale for not allowing us to do what many users have been asking for, for a while. Maybe there’s some technical reason that this is not possible to do?
Oh I agree, the whole raw RGB thing is ridiculous this day in age.
Publish and archives are megabytes. All media can be DWAB.
It’s been solved.
everything else you can export allready, just timelines are left.
will that support ALL effects from flame? so that we can just export and import these as bascially archives?
only solved if all artists know what makes managed media and what does not.
MY archives are megabytes, as are yours, trying to stay on top of freelancers is a challenge i find.
idk WHAT they are doing but i constantly have multi-gigabytes of random stuff in the archives still , if there was a way to just FORCE no media to be archived THEN it would be solved.
Logik Projekt. Cron job auto archives. Anything more than a gig gets flagged and reported.
Yes, there are technical limitations related to how the cached media is written to the archive that prevents using compressed media. If that was not the case you would have got this capabilities long time ago. But no worry we have plans to make all this easier in the future and we will let you know when available.
Bring back Backdraft
no - don’t
Thanks, Stephane.