Rian Johnson Response Round 2

Rian Johnson has posted a rebuttal to our previous round of responses. I’d like to go through some of what he says there.

In my response to his original article, I pointed out that the necessity of optical low-pass filtering means that a native 1080p camera isn’t going to resolve a full 1080 horizontal lines of resolution. Johnson says:

-The IDEA of an optical low-pass filter is to fuzz or blur resolution information that is SHARPER than the sensor can even see — not to blur information that it CAN see. So the mere fact that there is a low-pass filter does not in itself prove that resolution is lost (an underperforming low-pass may not fuzz ENOUGH and create aliasing without reducing resolution at all). So, even though a REAL low-pass filter as opposed to an IDEALIZED one can reduce resolution, the mere fact of a low-pass filter does not in itself prove that resolution is reduced (at least not measurably).

In practice, it does. Nobody knows how to make optical low-pass filters with a hard cutoff. If you filter enough to avoid aliasing (which is extremely undesirable in motion imaging — far more so than with still photos), you’re going to lose detail that the sensor could have otherwise resolved as well. One way to avoid this is to oversample and then downscale digitally — as the Red One does when shooting 4K for an HD deliverable. Aliasing can be introduced by digital downscaling as well, but digital scaling algorithms can be more finely tuned than physical filters.

-Our article points out that 1.8K is MORE THAN ENOUGH for theatrical resolution, so even if the low pass filter fuzzed the 1.9K image to 1.8K (which is extreme), it’d still be sharp in excess of the standard. There is no reason to think that Sony has gaffed the design even the amount mentioned. Additionally, it is not mentioned in your refutation that Red also has a low-pass filter and that it is much more difficult to optimize a low-pass filter for a single-chip (like Red has) than it is for 3-chips like F23 has.

It’s true that the resolution “loss factor” due to low-pass filtering is higher with single-chip bayer cameras than with three-chip cameras. Bayer sensors need more aggressive filtering to avoid chroma aliasing artifacts. This is one reason I mentioned the results of actual resolution tests with the Red One.

As for the discussion about whether 1.8K is enough for theatrical exhibition… that isn’t really a technical matter that can be settled one way or the other. Johnson seems to believe it’s enough that once you achieve it, resolution is no longer worth worrying about. I’ll acknowledge that that’s often the case. As I’ve pointed out before, this is more resolution that one finds in a typical release print. But it’s not always the case.

In response to my comments about how stills photographers often shoot far more resolution than they need, Johnson says:

-Still photographers often do extreme reframing by cropping. Motion pictures almost never do this (at least not more than a tiny bit that has no practical effect on resolution). Motion images ALWAYS color correct and need rich image information and almost NEVER crop in any meaningful way — the analogy to stills is meaningless, because, in motion, color information is constantly used to adjust the image with color grading, while resolution is almost never used to do “cropping.”

I agree that it’s true that motion images are rarely cropped. But Johnson just takes it for granted that this is how motion imaging works. I believe cropping is more common in the stills world not because it wouldn’t be just as useful in the motion picture world (particularly for e.g. documentary work), but because technical limitations have made it much more difficult to do in the motion picture world. Even with film it’s not advisable. A motion picture negative is significantly smaller than a 35mm photo negative, but is (generally) presented at a much larger size. There’s much less room to crop and still maintain acceptable resolution. Having enough resolution to get away with cropping a bit is a legitimately useful feature.

Moving on to color depth, Johnson says:

We are clear now that we’re talking about quantization of the camera (not necessarily of the photosites themselves) — and you may notice that our argument isn’t diminished at all when we clean up our wording to conform to your stringent standards. Sorry that we worded it too loosely the first time, but the reality is that F23 and Genesis gather 42-bits of REAL DATA ABOUT THE IMAGE per pixel (before mapping to 10-bit-per channel or 30-bits-per-pixel) whereas the Red gets 12-bits-per pixel. 30-bits represents over a billion unique colors/luminances whereas 12-bits represents 4096. That’s a hell of a difference.

Um…. this response has absolutely noting to do with the way bayer sensor cameras produce color images. Yes, the Red only records 12 bits of color information per photosite, but the color of a pixel in an RGB image produced by processing a raw bayer-pattern image is never based on the value of a single photosite. It couldn’t be; a bayer camera can’t produce an RGB color based on the value of a single photosite, because each photosite only detects a single color.

The value of every pixel in an RGB image produced by a Red One is derived from three color channels, just as it is with an F23 or a Genesis. Those color channels each contain 12-bit linear data, comparable to the 10-bit log data contained in each color channel of an F23 or Genesis. It’s true that the channels aren’t full resolution, but the Red exceeds Johnson’s standard for resolution, so that doesn’t really come into play in this discussion.

This is absurd. You’re saying that the higher the resolution and the higher the compression, the better the image, no matter what.

I was very careful to not say that. I merely said that higher compression ratio + higher resolution don’t necessarily produce worse images. The uncompressed SD vs. Redcode 4K is merely an extreme example to make a point, namely that less compression isn’t necessarily better.

As we pointed out, the thing that you CAN quantify is how hard the scheme has to work — and you say wavelet is more efficient (that’s in general, not in the specific case) — but RedCode had better be more efficient, because Red is a LOT more compressed than HDCAMSR and it has to be a LOT more efficient just to look AS good.

Look, I’m not saying HDCAM SR compression is bad. But it was designed when processors were slower, and it was designed to be the core of a real-time workflow. As a result, it’s not at all far-fetched that Sony and Red made rather different tradeoffs regarding computational requirements vs. compression efficiency.

And there are some other factors to consider. Raw data is often more compressible than processed data — there’s no artificial detail introduced by sharpening or other image enhancement that has to be preserved by the compression engine. Additionally, we both agree that at 100% size bayer images are softer than the images produced by RGB cameras, which also makes it easier for the compression algorithm to squeeze things down a bit more.

When you combine all of these factors with a more efficient (but more computationally intensive) compression algorithm, the difference in compression ratios isn’t nearly as startling. There’s no doubt that the Red One compresses data more. But the difference isn’t nearly as significant as comparing the compressed file sizes to uncompressed DPX frames initially suggests it is.

All due respect Chris, but no, actually, this is where you’ve missed by the widest margin. Raw is indeed a good way for Red to design their camera: it’s an advantage that Red has over an imaginary Red camera that’s designed a different way, but it’s not an advantage of Red over HDCAMSR. Raw is a description of WHEN YOU DEBAYER. Bayer is a subsampled kind of sensor. F23 and Genesis don’s subsample, so there’s no question about WHEN to debayer.

Recording raw sensor data isn’t just about whether you debayer in-camera. It’s also about whether you bake-in color settings, curves, sharpening, etc. in-camera. In principle someone could build a raw three-chip (or RGB striped sensor) camera. Actually, that’s basically the Viper in FilmStream mode, come to think of it. The F23 and the Genesis don’t really have raw output modes. They don’t record sensor data, they recorded processed video images. If your on-camera settings are wrong, you’ll throw away data that you might have wanted to keep. And it’s important to note that the definition of “wrong” is not some objective technical thing that professional operators can avoid. It can change if, for instance, the director decides in the grading room to make a different sets of creative decisions than the ones that were dialed in on-set.

Finally:

The only thing we’re refuting is the phenomenon where people try to quote specs to show that Red is a technically better CINEMA camera. F23 and Genesis see and record MORE INFORMATION ABOUT THE IMAGE THAT IS IMPORTANT FOR THEATRICAL CINEMA.

The F23 and the Genesis are certainly very impressive offerings. But as this entire discussion has demonstrated, the situation is somewhat more muddled than the previous two sentences indicate. The F23 and Genesis do offer a bit more dynamic range and they are, at least at this point, somewhat more tested and robust systems — particularly taking into account all the HDCAM infrastructure out there in the world. The Red One captures more resolution and has, in my opinion anyway, a better workflow for cinema where real-time isn’t critical.

2 Responses to “Rian Johnson Response Round 2”

  1. David Newman says:

    Chris,

    While there are valid points on both sides, I want to address the technical weakness in your compression argument regarding efficiency. It is absolutely true in general that wavelet trumps DCT, particularly under heavy compression, yet HDCAM SR is not heavily compressed at 4:1 (440Mbs SQ mode.) At the higher data rates wavelets only have a minor advantage, such that other factors like entropy encoding techniques start to play a bigger role in quality. HDCAM SR compression is I-frame studio profile MPEG 4, and was developed around the same time of JPEG2000, the basis of RedCode, so I don’t think is it fair to say it was “designed when processors were slower” any more than JPEG2000 was, both trade off computation speed for improve quality (requiring hardware for RT encoding and decoding.)

    It is true that compressed bayer source “images are softer than the images produced by RGB cameras”, and this does produce a lower compressed date rate, but that is not about the efficiency of compression. This does explain some the disparity in the data rates, but not enough to suggest compression quality matches that of HDCAM SR.

    So the argument of compression efficiency really rests on “Larger images are generally more compressible than small ones…”, totally true if we compare a 4K 4:4:4 to 2K 4:4:4 encodes. Unfortunately RAW doesn’t work this way as adjacent pixels are not correlated (green filtered photo-sites are next red or blue) so you can’t compress a single 4K RAW plane efficiently. A 4K RAW image is compressed as four separate chroma channels of 2K. So the resolution efficiency advantage doesn’t exist here, as they both are encoded at 2K, one is 2K 4:4:4 and the other is 2K 4:4:4:4. HDCAM compresses its 3 channels to 440Mbits/s, while RedCode compresses more (4 channels of 2K) to around 250Mbits/s.

    RedCode is excellent at compressing 4K RAW as much as it does, yet that should be considered a medium level compression when compared with HDCAM SR’s lighter compression. So Rian Johnson is correct here. RedCode’s design goals are completely different, allowing 4K RAW to be captured to Compact Flash, something that 4K 4:4:4 SR equivalent won’t be able to do for many years.

    David Newman CTO, CineForm http://cineform.blogspot.com

  2. Chris Kenny says:

    Thanks for the response, David. No doubt you know more about image compression than I ever will. Just to be clear, I wasn’t intending to argue that Redcode data isn’t more compressed than HDCAM SR data, merely that the difference isn’t as significant as the standard Rian uses (essentially comparing the size of rendered DPX files to the size of the original frames and discounting other factors) suggests it is.

    As far as JPEG2000 vs. HDCAM SR… it’s true JPEG2000 has been around for quite some time. But it wasn’t immediately implemented as a motion picture codec, where the necessity of compressing 24 frames a second (or more) on a completely reliable basis regardless of scene content imposes extremely stringent requirements. The frame rate limitations in the Red One’s compression engine and the only recently solved issues with codec errors in high-detail scenes seem to suggest this is challenging to pull off even on today’s hardware, though you’d probably be able to speak more on that subject than I can.

    And thanks for the info about how bayer images are compressed… I’ve been trying to wrap my head around how fractional-resolution decodes could work with bayer images. Breaking out the color channels before compressing answers that question. I’ve updated the post for accuracy, removing the reference to Red’s larger images being easier to compress.

Leave a Reply