This is basically a rundown of the entire end-to-end system, starting with the sensor and working its way into recording media and post workflow, focusing specifically on points that impact on directly on workflow. Why? Well, I started writing a post just about workflow itself, and I realized I’d need to discuss RAW, which requires discussing the fact that Red records RAW data, which requires discussing how the sensor works…. This post will provide background on all of this stuff. An upcoming post will go into some of the specifics of a Mac-based desktop workflow for Red footage (well, to the extent that I can be specific, not having the camera yet).

I’ve been over a lot of this previously in the blog, but the info is pretty spread out here (and even more difficult to piece together from reading posts on RedUser), and there’s much more information out there now about how everything works. Red is different from most other cameras people are familiar with, and I’m going to do a lot of comparing and contrasting along the way.

Ready? Here we go.

1. Capturing

Red has a single large bayer-pattern sensor.

OK, so what’s a bayer-pattern sensor? Most digital imaging systems use one of two methods of capturing images.

More is more?

The approach most common in professional and prosumer camcorders is to split red, green and blue through a prism, and record them onto three separate chips. This approach is beneficial, because it allows a camera to sample all three colors at every point in the image. However, there are also some serious drawbacks to this approach.

First, off, as a general rule, the less glass is in your optical path, the better; having a prism in your optical path can introduce certain types of artifacts. Second, it’s nearly impossible to make three chip systems with chips over a certain size; it’s just too hard to make prisms for them. Having a large sensor, of course, is essential if you want to get shallow depth of field, an essential creative tool. Finally, most of the best lenses in the world (for shooting narrative features, anyway) are designed to work with 35mm motion picture film cameras. A lens designed to project light onto a single film plane doesn’t work with a three-chip system. (Well, there are messy workarounds, but they’re beyond the scope of this post.)

Less is more.

Presumably for the reasons mentioned above, Red decided not to go with a three chip design. OK, but if you only have one chip, how do you record three colors? There are some exotic approaches like the Foveon X3, but by far the most common approach (used, for starters, by nearly every digital still photo camera on the market) is to use a technique patented by Dr. Bryce E. Bayer in in 1976: the bayer-pattern sensor.

A bayer-pattern sensor is a light-sensitive chip (obviously) with a red, green or blue color filter over each of its photosites (see the illustration at the link above; it’s much easier than trying to understand a written description). For any given photosite (a photosite is an individual light-sensitive element), the camera captures color data for one channel. (It’s slightly more complex than this, because the filters don’t actually eliminate all other wavelengths, but that explanation will do for our purposes.)

What you’re left with is a single channel of image data that, if you looked at it directly, would look like a grayscale image with a checkerboard pattern all over it at the pixel level. This is a RAW image.

2. Recording

Red has a fairly unique approach to recording, which has many implications for workflow.

Your data, RAW and uncut

One of the things that makes Red nearly unique among motion picture cameras is that it takes the RAW bayer data from the sensor (see above), compresses it (see below), and stores it still in its RAW form, a feature it shares with many higher-end digital photo cameras.

Sliming down

Shooting 4K, Red is capturing a RAW image with a resolution of 4096×2304 (actually, cameras can currently only capture 4096×2048, but Red is going to enable the full resolution in a downloadable firmware update). Red’s analog-to-digital conversion happens at 12 bits. If we multiply out 12 bits * 4096 * 2304, we find that every frame Red captures should take up 113,246,208 bits, or in slightly more convenient units, 13.5 MB. That means shooting at 24 frames a second, Red can generate 324 MB of data, every second.

What do you do with it all? Just to record it you’d need at least six hard drives in a RAID 0 array (probably more like 8-10). And even if those were 1 TB drives, the largest currently on the market, you’d still fill the entire 6 TB array with less than an hour of footage! While there are some situations where this kind of setup might be practical (and Red can work with it, sending uncompressed data out through an optional optical port), it’s not very practical for most shooting.

Red’s solution to this problem is REDCODE RAW, a compression algorithm designed specifically for the Red camera. The camera takes that 324 MB of data and applies about 12:1 compression, squeezing it down to around 27.5 MB/s — less data than uncompressed standard definition video.

RedCode RAW is a wavelet compression algorithm. In terms of image quality, this means it can deliver much better quality than what can generally be expected from the other major class of image compression algorithms, DCT algorithms. If you’ve ever seen a JPEG, watched MiniDV footage, or watched a DVD, you’ve seen an image compressed with a DCT algorithm. Wavelet algorithms have much less objectionable artifacts (no visible blocking, for instance). This comes at the cost of higher computational cost, but processors are fast enough now that this is no longer a problem.

Wavelet algorithms also have another property that makes them particularly interesting for Red’s application, which will be discussed in the post workflow section.

It’s a data world

Red records footage as files on compact flash cards. Later, it will be able to record directly to a disk-based digital magazine called the RED DRIVE, or to various other sorts of sold state memory.

The important point here with respect to workflow is that capturing footage through a deck (or using the camera as a deck) is, with Red, an obsolete notion. Footage isn’t captured in the typical sense; one simply attaches the recording media to a computer with a standard interface (the CF cards can be read in a normal CF reader, the RED DRIVE will connect over USB or FireWire), and copies footage files over like normal data files. This clearly has a huge number of benefits, which are so obvious there’s not much point in elaborating on them here.

3. Post Workflow

RAW diet

Anyone with experience shooting RAW on a digital SLR camera is aware of the benefits that feeding RAW data into your image processing pipeline can have. Sharpening, white balance, and a host of other parameters can be tweaked in the comfort of your office, looking at a nice big reference monitor, instead of being “burned in” when you shoot. Red shares all of these advantages, and even provides a bit more flexibility. For instance, since Red uses exclusively digital gain, you can actually choose your ASA after the fact (sort of; I’ll do a future post on this subject). Red’s software also allows the user to tweak the parameters of the algorithm (called a demosaic or debayering algorithm) which converts that bayer checkerboard pattern (see above) into a normal RGB image. Do you want a smoother image, or do you want the algorithm to extract more detail? You decide.

And, of course, none of the changes you make change the actual data in the original REDCODE files (which have the entertaining file extension ‘r3d’). They’re just stored as metadata (data about data), and can be discarded or modified at any time.

It’s also possible to decode the RAW data differently depending on whether one wants a higher quality image, or an image that can be decoded with less processor power (e.g. for real-time playback).

Catch the wavelet

Remember I said wavelets have another interesting property relevant to post workflow? Wavelets make it very easy to extract fractional resolutions. For instance, if you have a 4K wavelet-compressed image, and you want to extract a 1K image from it, this can be done with relatively little processing power — vastly less than decoding the entire 4K image and scaling it down.

Playing back 4K in real-time is something that isn’t possible on widely available computing hardware at the moment, and there’s not much point in it anyway, since almost nobody has hardware that can actually display a 4K image. This makes the fractional resolution decoding enabled by wavelet compression extremely useful, particularly combined with the ability to decode RAW at varying qualities (see above). Between these two factors, data suitable for almost any purpose — from an on-set rough edit, to outputting digital dailies, to a 4K final conform, can be extracted directly from the original REDCODE RAW data files.

And that’s a good place to stop for today, because the next subject, namely how that REDCODE data gets fed into an actual post pipeline and what one can do with it there, is sufficiently complex to merit is own fairly long post.