The Red Experience, Part 2: The Edit
Where part 1 of this series… was mostly theory, anticipation and about establishing best practices for RedCode data, this part is all reality: what happens in practice when you try and work with it.
After all, the vast majority of discussions of Red camera workflow are necessarily theoretical, after all very few people are using it for anything other than test footage. The editing stage is often the first stumbling block, as actually getting any of the footage into an editing suite to play around with can be challenging. There’s also a much more problematic issue that deserves attention: ensuring that the finished edit can actually be used for an online somewhere.
There is a popular workflow with Red footage which is to edit the R3D files directly in FCP. The benefit of this is that it is very simple: you just load the QuickTime proxies into a project and snip away as normal. You can even do your online in FCP if you wish, putting Final Cut’s colour correction and effects tools to good use. You can then export to a wide variety of formats, including some uncompressed* variants.
*Note: I’ve not done any tests on this workflow to see if working in this manner produces a “true” uncompressed result (compared to converting the RedCode data directly to an uncompressed format first, and editing with that). It is possible that somewhere along the path, probably at the Red proxy file, some amount of compression is introduced.
However, I’m not a big fan of workflows like this, because they make the process proprietary and reliant on specific software configurations. It’s entirely feasible that at some point RedCode will be treated in the same manner as formats such as DV, universally recognised, and with predictable results regardless of your editing system. Furthermore, we didn’t want to limit ourselves to having to use FCP for cutting (although ultimately that was exactly what we used). And finally, I was concerned that the cases of clips with duplicate names would give us grief when un-picking the edit in preparation of the online.
The method we used in the end was to convert everything using the Redline command-line processor (from Red), by creating a batch script using our Redemption… database. We set everything to output 1920×1080 DVCPROHD movie files (which would retain the original timecodes) but prefixing our own reel numbers to each file. There were a couple of bugs in the Redline code (which are being addressed) that prevented the iso value of each file being read automatically so we had to plug those numbers in ourselves. It was also apparent that it was necessary to apply a gamma-curve during the conversion process to prevent everything looking flat: helpful for the online process perhaps, but not so much for the edit.
We then had a folder of movie files that could (in theory at least) be loaded into any editing system. We went with Final Cut, and an additional step was that we had to change the reel number FCP had assigned (based on the filename I assume) to our reel number.
That done, the editor took over and started to cut, as if working with any other footage. Meanwhile, we could start looking into getting the material prepped for the 4k online.
As a side note, one of the other things we were able to do easily due to the digital nature of all this was have our proprietary database automatically match the shoot notes to the Red data logs, so we were also able to produce a reference log for each clip.
The third and final part will look at using Autodesk’s Lustre to online the 4k files.