This post is going to be a rundown of Red desktop workflow, and will look at both where it stands now and where it’s headed in the future. I had been holding off on this post in the in the hope that REDCINE would be released in time for me to discuss it a bit, but that seems to be taking awhile so I think I’ll just go ahead.
If you haven’t yet, read part one of the workflow primer, which discusses RAW acquisition and wavelet compression, both essential to the desktop workflow equation.
As things stand now, there are three ways to do something useful with Red footage, once you get it onto a computer. The first is to feed it into Assimilate’s SCRATCH, which has native support for REDCODE. I’ll discuss that workflow if I ever get a chance to play with a SCRATCH system for long enough to have anything useful to say about it. Until then, though, I’m going to focus on the other two methods of getting Red footage into apps in a usable format, and on where things are headed in the future.
1. Red Alert!
Red Alert! is Red’s interim RAW processing app. It’s sort of like Adobe Camera RAW, but for RED footage. One sets white balance, exposure, what curve to apply to the image (linear, Rec. 709) and all the other stuff one doesn’t have to set in-camera, because the camera is shooting RAW footage. Red even lets you tune the debayering algorithm, to get a smoother image or to try to extract more detail.
Red Alert! can review footage with the chosen settings and (this is the important bit) render it in a couple of ways, at 2K or 4K. If you’re feeding your footage into a traditional DI pipeline, you can render out DPX or TIFF files. A TIFF or DPX file stream, though, will run around at least a couple of hundred megabytes a second, though, and that’s at 2K, which makes this workflow a little heavy for anyone without a fairly serious post budget. So, this post (and this blog, for that matter) is going to focus a bit more on the other workflow.
2. The REDCODE QuickTime codec
RED has another way to get footage into apps in a usable format, one that’s relatively undeveloped now, but will probably be the anchor of low-budget in the future. Red has developed a QuickTime component which understands REDCODE. The camera, of course, doesn’t record directly into QuickTime files, but the Red QuickTime component works around that in a neat way: QuickTime reference movies. What are QuickTime reference movies? They’re tiny MOV files that simply contain some metadata, and a pointer to a Red footage file (a .r3d file). These reference files are generated automatically by the camera with recent firmware builds. One can also generate them in Red Alert!, in which case they’ll reflect the RAW processing settings one has chosen in Red Alert! The camera and Red Alert! generate reference movies for multiple resolutions, so you can feed 2K, 1K or 0.5K into QuickTime apps.
This approach allows one to work with REDCODE data without having to recompress it or convert it to formats that take up much more space. And, of course, since you’re working directly on the original RAW data, you have access to everything the camera captured (more on that later).
It does presently have some limitations, however. REDCODE is an acquisition codec, and optimized with that in mind. It’s intended to provide maximum quality at a given bit rate. Unlike, say, Apple’s ProRes, it’s not designed to be light on your editing system. One needs a fairly fast system to back the 1K reference movies in real-time, and I haven’t heard reports of the 2K versions playing back reliably in real-time even on very high-end machines (contact me if you’ve heard differently).
Another limitation is that the QuickTime proxies currently can’t spit out 4K at all, and they use a lower quality debayering algorithm than the best Red Alert! has to offer.
Finally, one can’t really edit directly with REDCODE footage at the moment using the QuickTime reference movies. REDCODE RAW is read-only (it makes sense that you can’t render out in a RAW format), so you can’t set REDCODE as the codec of a Final Cut Pro timeline. This means you have to drop REDCODE footage into an FCP timeline set to use another codec… which means you have to render everything before playing it back.
The good news is, it’s probable that all of these issues will disappear as the workflow matures. More code optimization (and, of course, the ever-increasing speed of computers) will no doubt make real-time 2K (and even 4K) playback of REDCODE footage a reality on the desktop. Red will almost certainly offer more options for how to decode data though QuickTime reference movies, allowing this pipeline to be used for everything form low-quality previews, for full-quality 4K footage to be feed into compositing programs, etc. And, of course, native REDCODE support has been promised in a future version of Final Cut. Presumably this last will require a version of the REDCODE codec that has been modified to support encoding (I would guess to an RGB variant of REDCODE which can be mixed with REDCODE RAW footage in a timeline).
As this workflow matures, it should be possible to do an offline edit with real-time performance (but from reference movies — so there’s no need to waste lots of space and render time on separate proxy files), and then go back and do a full-quality conform, by swapping out one set of QuickTime reference movies for another.
Until that day comes, the QuickTime proxy movies still provide a fast way to convert Red footage into other formats, like ProRes, so one can offline (or even online, for many deliverables) in those formats. This function of QuickTime proxy movies should become obsolete when REDCINE ships, however, as it will be able to directly export to different QuickTime formats, and should offer more options when doing so (like full quality debayer).
Just to clear up one common misconception — Final Cut Pro will not be limited to 8-bit when working with REDCODE footage. Yes, Final Cut only does 8-bit for RGB. However, it offers a full 32-bit 4:4:4 YUV pipeline. A codec can work around the 8-bit limitation for RGB by simply appearing to FCP as a YUV codec — and Gramme Nattress has mentioned in several places that Red’s QuickTime component does precisely this.
I should have a post later in the week about what a practical low-budget indie workflow for RED footage would look like as things stand right now.
