Updated April 29, 2009
Native support for REDCODE, the RED ONE camera’s RAW image format is a subject of considerable interest in the post production community.
We’ll take a look at the implications of the native and non-native RED support.
RAW image file format is a straight data dump from the camera’s imaging sensor. RED ONE camera uses a Bayer pattern color filter array. Each Photosite (pixel) in Bayer pattern is sensitive to either one of the tree primary colors. Pixels are arranged in an alternating pattern designed to optimize true color stimulus. Since each pixel represents only red, green or blue the image must be debayered before use.
While a RAW image resembles the photographic subject, it is far from being usable prior to debayering. Good quality digital still cameras are similar to RED ONE in the way RAW image is acquired and presented for post-RAW processing.
Debayering is only one of the steps in the process of converting an image from RAW to a viewable picture. Other steps may include OLPF (Optical Low Pass Filter) processing, bit depth conversion, gamma encoding, and various types of color processing. The actual steps depend on the manufacturer and are often closely guarded secrets.
Some manufacturers allow third party processing of their RAW images while others don’t. RED Digital Cinema’s REDCODE is an encrypted format closed to direct third party processing. This distinction is important in order to understand the native vs. non-native RED support.
Native RED Support
Initially Assimilate’s Scratch and ScratchCine were the only third party products with native RED support. Adobe was the second company to partner with RED Digital Cinema and gain direct access to REDCODE in Premiere and After Effects. After NAB 2009 DVS Clipster is the newest third party box with direct RED support.
Native support means that Scratch and all other “native” systems are able to work directly with the RAW data contained in .R3D files. No conversion stands between these systems and the data captured by the RED ONE camera’s imager. The data is processed with an internal debayering algorithm.
There is a very important concept to consider when it comes to RAW image processing in RED ONE. The only two controls that alter the way image is captured are the lens aperture and the frame rate. All other settings such as ISO speed, color temperature, etc. have no effect on RAW data whatsoever. They are merely suggestions to the debayering algorithm on how to process the image.
This is a counterintuitive concept to those of us who come from the world of film where the choice of tungsten or daylight film determines color rendition. CMOS imaging sensors are color temperature agnostic (not entirely true but that’s a topic for a whole another discussion).
Film stocks rated for higher ISO speeds differ in chemical formulation from lower ISO speed stocks. High speed setting in a digital camera like RED ONE can not magically make the CMOS sensor more or less sensitive to light. The sensor’s sensitivity is what it is. Higher ISO speed dialed into the camera does not make it more light sensitive. It only tells the debayering process to “push” the processing a certain amount.
A post production tool like Scratch can access this unprocessed data and it is up to it to push, pull, alter color temperature or do any other needed adjustments. The “native” comes from the fact that the image is accessed by the DI system in its native RAW form. Theoretically, this full access can allow a RED native tool a wider range of adjustment than possible when RAW images are converted to an intermediate step as in a non-native process.
Non-native (Direct) RED Support
Almost all DI manufacturers offer non-native RED support in their products since NAB 2009. These manufactures prefer to refer to the implementation as “native RED support” although the process is entirely different from the true native approach as described above.
The non-native direct RED support renders remarkably high image quality and when processed properly by the colorist there is no loss of image data.
This process does not have direct access to the REDCODE RAW material. Images are debayered through RED Digital Cinema supplied SDK (Software Development Kit) and converted to another image format for storage and color manipulation by the host digital intermediate system.
For example, Digital Vision’s Film Master processes all images to 10-bit or higher DPX log or TIFF file format prior to color processing. All RED specific processing such as color temperature, ISO speed, etc. is completed during this initial step. Once the DPX files are created all these color decisions are hard wired into the files. An .R3D file can be reimported with updated settings at any time.
Practical Differences
There is an advantage to having a direct access to RAW data as in Scratch because of inherent benefits of color processing during debayering stage. Significant color changes during debayering typically produce fewer artifacts.
One drawback of non-native direct RED support through the SDK is that it is difficult to achieve real time playback speed due to the SDK debayering step.
The real world difference between the native and non-native direct RED support is non-existent or minimal in most practical situations but there is a potential for faster operation in native environments when heavy color changes need to be performed during client supervised sessions.
Igor Ridanovic is a co-founder of RED Los Angeles User Group