There’s a certain demographic which seems to sit around thinking of reasons why the Red One can’t possibly be any good. We’ve all run across these arguments. One that has really been bugging me recently is the notion that RedCode compression somehow constitutes, essentially, cheating; that Red shouldn’t really be considered a high-end camera because it shoots compressed footage.

The notion that uncompressed is always better for a professional camera shows a complete lack of understanding of the trade-offs involved with this sort of decision. Sure, uncompressed is better if all other things are equal. But all other things aren’t equal.

What particularly annoys me is the notion that the Red One is somehow less professional than cameras which output uncompressed 1080p as their final product. Modern compression algorithms are extremely smart about what data they discard. The idea that you’re better off with an uncompressed image with a much smaller number of total pixels simply doesn’t hold up to even the most cursory analysis.

Even very low bit-rate consumer formats like HDV, when shooting HD, produce much better looking images than uncompressed SD, despite having far lower bit rates. (And HDV compression for 1080p footage is something like 85:1 or 90:1 compression. RedCode 28 is 12:1, and with a much more advanced algorithm.) You’re far better off capturing lots of detail and having a modern compression algorithm figure out what it can safely get rid of than you are capturing less detail in the first place, or capturing lots of detail but throwing lots of it away immediately using more primitive techniques like downscaling or subsampling chroma.

OK, so why doesn’t Red just record uncompressed 4K bayer, instead of compressed 4K bayer?

I’m quite confident in saying that given today’s technology, the Red One is a far more compelling product because of RedCode than it would be if it only shot uncompressed data. In fact, the camera wouldn’t be nearly as significant to the market if it didn’t shoot to a compressed format.

RedCode is what allows you to shoot to CF cards and Red Drives, rather than being tethered to a RAID the size of a mini-fridge. It’s what allows footage to be downloaded in a practical way on-set. It’s what allows you to play back footage from a single SATA or FireWire 800 hard drive, and store about 10 hours of footage per terabyte, instead of around 50 minutes.

Of course, you don’t get all of this for noting. The Red One probably could probably use less power and run cooler if it didn’t have to do 4K wavelet compression in real-time. And there is some loss of image quality vs. a totally uncompressed 4K image.

But the fact is, the Red One wouldn’t be a remotely practical camera for the vast majority of the projects it’s being used on, if Red had bought into the myth that professional recording must be uncompressed. RedCode is the major factor that makes the Red One usable by low-budget indies. Without RedCode, the data situation would simply be unmanageable for low-budget indies, both on-set and in post. Without Redcode this blog, which after all focuses on the technical issues surrounding low-budget indie filmmaking, probably wouldn’t talk about the Red One at all. As it is, that’s practically all we talk about….

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.