Red Workflow Primer #2
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.
Thanks Chris! This is exactly the type of detailed information new red users need. It’s nice to find it here upfront without having to wade through all of the stuf on reduser.net
A good layout of the facts as usual Chris… thanks. I definitely prefer the idea of keeping everything in the RED/Apple family, but I’ve just recently begun to more seriously consider the prospect of a Cineform post workflow. I’m not too impressed with the quality of QuickTime proxies so far. I know that will improve, but it seems like there is just going to be too much power required (for the immediate future at least) to decode the Red Raw files on the fly while editing and viewing high-quality encodes. This leaves us with Pro-res as a viable option and one that I was planning on using in our workflow until I started reading more about Cineform’s 4K solutions. David at Cineform is claiming that 4k files work well in a Premiere 2K sequence. I’d like to make sure this works well in FCP too. I don’t care for a 4k finish myself, but I would definitely like to retain the re-framing (plus extra for stabilization) that 4k in a 1080P or 2K timeline provides.
Sorry for the long comment post, just wanted to mention it in case, like me, you too were aware of Cineform, but not really considering it as an ideal alternative in the Red post workflow. I LOVE the talented folks at RED, but they have a lot on their plate and are a fairly small team. Cineform is small too, but they are essentially solely focused on their codec so they can pour more resources into just the post workflow.
I’m a RED enthusiast who will be getting Scarlet next year.
I’m hoping that you can expand this series to include REDCine, since that seems to be the up and coming tool.
Even after reading the descriptions in RED’s FAQ, I’m not clear on what REDCine does.
Thanks!
Hope you’re enjoying your REDs!
D
Yeah, I’ve been meaning to to a more comprehensive and up-to-date workflow review. Hopefully I can do it later this week, if not, probably next week.