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.

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