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.

So, director Rian Johnson has a critique of Red “hype” that has been attracting some attention in the Red community recently. The first version of it was rather rant-like, but there’s now a new version up, which attempts to be more of a straightforward technical critique. Unfortunately, it still contains quite a few technical inaccuracies. I’m going to go through at hit on several of those here, but it might be a good idea to read the full post for context.

I’m breaking this into two posts because the first one was getting rather long. Second post will probably be up tomorrow.

Johnson argues that the Red One is over-optimized for resolution at the expense of other criteria, like dynamic range. As part of this argument he makes the case that 2K is enough resolution for a feature. This is largely true, but there are several mistakes in the evidence Johnson presents for this. For instance, Johnson uses the fact that Kodak defined 2K as a standard resolution for DPX/Cineon files as evidence that Kodak considers 2K sufficient. He says:

Note that Kodak could have made any specs they felt were required here to fully achieve the quality of 35mm film: for example, they could have prescribed a file that has more resolution and less color information. Here’s one they could have used: 4K pixels, 3 channels-per-pixel, and 8-bits per channel — that would have actually been the exact same file size as the spec they did choose, and they even could have said the word, “4K.”

There are two problems with this. First, 8-bit 4K frames aren’t the same size as 10-bit 2K frames. If we assume a 16×9 frame, 10 bit-per-channel 2K is 30 bits per pixel * 2,359,296 pixels, or 8.44 MB/frame, while 8-bit 4K would be 24 bits per pixel * 9,437,184 pixels, or 27 MB/frame, over three times the size. Oops.

Second, Kodak didn’t define 2K as the standard resolution for digital film scans. They defined it a standard resolution, alongside, you guessed it, 4K. It’s pretty widely acknowledged that a 35mm original camera negative captures more than 2K worth of resolution. Certainly 2K acquisition and workflow can provide a perfectly acceptable level of quality. It’s more resolution than ends up making it into a theatrical release print. But Kodak didn’t declare that 2K is the end of the road, and nothing beyond it is worthwhile. It’s true that most features are currently finished at 2K rather than 4K, but in large part this is simply because it’s good enough and technically much less of a challenge… not because nobody should ever want anything better.

The resolution discussion continues, with an argument that because the Genesis and F23 capture 2K (or something close enough to it), they capture enough resolution that resolution doesn’t matter, and therefore Red’s higher resolution is not a meaningful advantage.

There a couple problems with this argument as well. The first is that it assumes (at least in the case of the F23) that three 1920×1080 sensors capture full 1920×1080 resolution. This just isn’t so. All general-purpose cameras have optical low-pass filters to avoid aliasing, which results in a loss of resolution. So The F23 necessarily resolves something less than 1920×1080. Johnson is right, of course, that the Red One doesn’t actually resolve 4096×2304, of course. Bayer-pattern sensors like the Red’s do resolve a fair bit less than their raw photosite counts might imply. But several tests have now shown the Red One does resolve about 3.2K, or about 1800 horizontal lines, which is over 60% more than the absolute maximum the F23 could possibly resolve.

This argument also seems to take it for granted that nobody would ever need more than 2K resolution even for an original camera negative (or digital equivalent). While it’s true that, as noted above, 2K is higher resolution than a release print, 4K projection is likely to be quite common in the years to come.

And consider: most still photo photographers shoot everything at the maximum resolution allowed by their cameras, even when their photos are going to end up being displayed at less than a megapixel on a web page. Few would be happy if you suddenly told them they couldn’t do this anymore. It gives them the flexibility to reframe later, to repurpose photos for higher resolution media later, to do things like masking on a large image before scaling down to the appropriate size for the deliverable. The only reason moving images aren’t regularly shot this way is because it’s technically difficult to build cameras that can do it, not because it wouldn’t be beneficial.

The discussion moves on to bit depth, noting that high-end HD cameras generally have 14-bit analog to digital converters (ADCs) and record 10-bit data (with a log curve applied, though Johnson doesn’t mention this). Moving on to the Red:

The Red [...] (still just talking about the image before it’s recorded), is so busy trying to outperform the other cameras in just the one area of superfluous resolution that it hasn’t got to the full cinema quality of the other requisite aspects. They’re using up all their photosites on resolution (so they can say 3.2K or 4K is a bigger number than 1.9K) and are truncating color information. The Red sensor only has one pixel per channel instead of three, which means it is 3-times color subsampled. The Red sensor samples at 12-bit (compared to 14-bit on the other cameras) for conversion to digital (in a seemingly unpublished bit-depth).

This seems to show a bit of confusion. Photosites are analog components. They don’t sample at a specific bit depth; bit depth is a function of digital encoding. A photosite simply generates an analog electrical signal that varies in strength according to how many photons strike that site. This analog electrical signal then goes into an ADC, and comes out as digital data with a specific bit depth. In the case of the Red One, the ADC outputs 12-bit linear data, which is recorded as… 12-bit linear data. Applying a log curve to image data puts more of your pixel luminance values “in the right place” (it distributes them across the tonal range of the image in a more useful way), so Red’s 12-bit linear doesn’t really provide an advantage over the 10-bit log of cameras like the F23. But the Red One isn’t really at a disadvantage here either. And keep in mind that the Red One is recording raw bayer data. My understanding (and I admit I’m not an expert on de-bayering algorithms) is that when generating an RGB image from a 12-bit bayer pattern, one can actually end up with a bit more than 12 bits of color data.

So, does that initial 14-bit ADC conversion benefit cameras like the F23 and the Genesis in any substantial way? Given that 12 bit encoding allows the Red One to record everything from the sensor’s noise floor (the camera doesn’t artificially clip to black below a certain point like traditional video cameras) up through its sensor-clipped highlights without any noticeable banding in images (even when you push them around in post, within reason), it seems unlikely that a 14-bit ADC would make any noticeable difference.