Archive for June, 2008

In defense of compression

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….

Red releases first Build 16 firmware beta

We’re still here, we’ve just been rather busy. Regular updates should start again… about now.

See major new features and menu map. Camera owners can, of course, get it in the usual place.

The biggest enhancements are related to image quality. Red appears to have rather dramatically reduced compression artifacts and noise levels. 16:9 4K is also now far more practical to shoot and worth with, with the codec errors during recording supposedly fixed, and 16:9 4K QuickTime proxies now working.

Red has also introduced a new color space, REDSpace, that allows for better WYSIWYG exposure on-camera. Or, for those who work in a more technical way, you can now directly monitor raw, so you know exactly what the sensor is capturing.

Build 16 also introduces 1080p output in playback mode, though not for live monitoring, and many user interface conveniences and fix-ups, like user buttons that are now actually programmable, and the ability to adjust a range of parameters with the rotary encoder on the EVF.

Be warned, however, that Build 16 changes the format of R3D files. There are QuickTime plugins and RedAlert/RedLine builds for the new format, but not RedCine build that can work with Build 16 footage yet. So if your workflow relies on RedCine, you’ll probably want to hold off until that shows up (possibly as soon as next week).

Update: the Build 16 compatible version of Redcine has just been posted. Get it in the usual place.