Response to Rian Johnson #2
See part one of this post here.
Last time around we discussed resolution and color depth. This time, we’re going to take a look at compression and the implications of raw recording. Oh, and price.
Compression is easy to address. I already posted on this subject a couple of months ago. If you don’t feel like reading that entire post, the short version is that capturing a much larger image, even with a substantially higher compression ratio, is going to preserve more useful image data than capturing a lower resolution image. As a really obvious proof-of-concept thought experiment, consider the fact that the data rate of 4K shot in Redcode 28 on the Red One is about the same as the data rate of uncompressed standard definition video. Throw both of them up on a movie screen, or even a moderately sized HDTV, and there’s absolutely no contest. Similarly, a 4K image, recorded at a high compression ratio, can look substantially better than a 2K image recorded uncompressed or at a lower compression ratio. It won’t necessarily, of course. It depends on the details. But one can’t argue from principles that it will be worse. One has to actually evaluate the results side-by-side. Subjectively, Redcode holds up extremely well.
Johnson goes on to say:
Red’s literature would have you believe that all competing compression schemes are in the stone ages (they often use the word “wavelet,” which is supposed to prove that their compression, not just their vocabulary, is better), but we don’t think so — we think that other state-of-the-art cameras are also state-of-the-art.
HDCAM SR is a DCT-based compression algorithm, like JPEG. Redcode is wavelet algorithm, like (and, in fact, based on) JPEG 2000. These are well established facts. And the fact that wavelet-based algorithms are more efficient than DCT-based algorithms — and have less objectionable artifacts for image compression — is not particularly controversial. Wavelet algorithms require more computational power, which is why they’re often not used in real-time systems. But they do provide better results, i.e. higher image quality and/or smaller file size.
Johnson misses the mark by the widest margin, perhaps, when discussing raw workflow. He says:
Some people claim that the processing of F23 and Genesis “bakes in” a look that you can’t undo in post-production and therefore Red has more information about the image available in post, but this “baking in” problem is only true if you have bad settings in the camera (like, if you crush blacks down to zero in the camera settings). Actually, when the equipment is operated correctly, you have MORE information about the image in post from F23 and Genesis (which is our whole point through this article), because these cameras record MORE color (and luminance) data about the image — you get more breadth and depth, more range for color-grading from the richer HDCAMSR file. Also, the exact same “baking in” problem applies to Red’s processing software as it does to F23 and Genesis — if you have bad settings, you’ll truncate data. So, if trained professionals are handling the equipment (whether it’s F23, Genesis, Red Camera, or Red Software), then there will be no “baked in” data truncation.
I barely need to write a response to this, do I? The advantages of capturing raw data are, by now, probably quite obvious to the readers of this blog. Johnson tries to set up an equivalency here that doesn’t exist (”if you have bad settings, you’ll truncate data”). There are two problems with this. The first is that a camera recording the output of a 14-bit analog-to-digital converter to a 10-bit tape format will always throw away data. If you have everything set up correctly this shouldn’t be a big deal, but it does remain a mathematical fact.
Secondly, there’s a very large difference between baking in what might turn out to be the wrong data on set, and baking it in using Red’s post tools. In latter case, fixing things requires reprocessing some files. In the former case, it requires a reshoot. Dismissing this by saying the article is “about technical quality of motion imaging, not time and place of motion imaging”, as Johnson does in the next paragraph, is simply bizarre. This is a factor which, in the real world, can have substantial impact on the technical quality of motion imaging.
Sony has been able to build image processing software and native hardware that can fit inside the camera and do full-quality lossless processing in real time. Red didn’t build it on-board and they can’t do it in real time. That’s not an advantage for Red. Red’s image processing software has to work much harder than Sony’s because the camera only gathers one piece of data per pixel instead of three, and the processing software has to work hard to turn that subsampled data into an intelligible color image.
It is true that in some workflows, it’s beneficial to have a high-quality video image available for playback immediately, rather than after substantial processing time. Fortunately, you can do this today with Red footage via SCRATCH CINE. Sometime next year, you should, according to current announcements anyway, be able to do it with the dedicated hardware in the RedRay player, at up to 4K.
Finally, a word on a subject probably of some considerable relevance to most of the audience of this blog: cost.
We need to keep things in perspective. The cameras Johnson is comparing the Red One to cost ten times as much. Or more. The fact that the Red One is even being compared to them shows just how much Red has achieved. The fact that the Red One wins some of those comparisons is absolutely stunning. The Red One’s more significant feature, when all is said and done, is that it puts a high-end imaging tool — a tool which shoots at sufficient quality that its footage is suitable for any deliverable, right up through theatrical projection — into the hands of thousands of people who would otherwise never have access to such equipment.

