REDCODE

A major contributor to this article appears to have a close connection with its subject. It may require cleanup to comply with Wikipedia's content policies, particularly neutral point of view. Please discuss further on the talk page. (April 2010)

The topic of this article may not meet Wikipedia's general notability guideline. Please help to establish notability by adding reliable, secondary sources about the topic. If notability cannot be established, the article is likely to be merged, redirected, or deleted. (April 2010)

R3D file

Filename extension	.R3D
Type code	R3D
Magic number	DRED
Developed by	Red Digital Cinema Camera Company
Type of format	Media container
Container for	Audio, Video, TimeCode, metadata

REDCODE RAW (R3D) is a proprietary multimedia audio/video file format owned by Red Digital Cinema Camera Company and featuring lossy compression for video contents and lossless for audio contents. It is used as native recording format of Red digital cameras and recorded on proprietary Hard Disk Drives, CompactFlash cards or SSD drives, but can be extracted from there and be trivially handled in any file-based audio/video, IT or home environments.

Overview

All Red cameras record only in the REDCODE RAW codec. This codec has a constant-bitrate wavelet codec with a compression ratio from 18:1 to 3:1 which allows raw Bayer sensor data to be compressed for on-camera recording. For the Red One two variants were offered initially, one with a maximum data rate of 28 MB/s (224 Mbit/s), and one with a maximum data rate of 36 MB/s (288 Mbit/s). Firmware upgrades allowed the camera to record an additional data rate of 42 MB/s (336 Mbit/s). These bit rates represent compression ratios of about 12:1, 9:1, and 8:1 respectively.

Unlike cameras that record RGB data, Red cameras record compressed Bayer data. Recording compressed raw data allows white balance, gamma and other image processing parameters like sharpening to be set during post production. Adjusting these settings directly on camera does not impact the raw data that is actually recorded, but rather modifies metadata recorded alongside recorded images, which is accessible to software utilizing the camera's SDK. These meta-settings, called "looks" can be saved and applied to the camera's outputs to allow on-set crew to see an image more closely representing the director of photography's vision for the picture rather than the more "flat" look of the raw image data that comes from the sensor by default, while retaining the flexibility of the sensor data for post production.

Compression algorithm

Video streams within a R3D file are stored using a constant bit-rate, intraframe, wavelet-based codec with four channels (1 for red, 2 for green, 1 for blue), which is a variant of the well-known JPEG2000 algorithm for digital still images.

Decompression is not the only coding the video stream is subject to in order to be playable: since the video data recorded from the camera sensor (the Mysterium sensor in the case of the Red One camera) are stored in the geometrical order they are transferred, a Bayer-patterned frame sequence is generated in the first place, which needs later transcoding (deBayering) to obtain a visible RGB stream. For that reason, R3D is a raw image format for video. A similar file format (or wrapper) is the Adobe CinemaDNG.

Audio streams (mono, stereo or 4-channels) are coded, uncompressed, in plain 48 kHz, 24-bit PCM.

REDCODE is a lossy codec, meaning that decompression does not fully restore the original image data captured by the camera. Red claims the codec is "visually lossless", suggesting that the information loss is not visible to the naked eye when images are viewed. However, sample images detailing noticeable artifacts have been posted on the manufacturer's forum. Because Redcode is a wavelet codec, similar to CineForm RAW and JPEG2000, the nature of these artifacts is different from "blocking", characteristic of traditional compression algorithms.

Naming convention

RED Digital Magazine (REDMag)

Filename extension	.RDM
Type of format	Folder
Container for	RED Digital Clips

RED Digital Clip

Filename extension	.RDC
Type of format	Folder
Container for	REDCODE RAW footage
Contained by	RED Digital Magazine

REDCODE RAW footage

Filename extension	.R3D, .MOV, .rsx
Container for	audio/video + metadata
Contained by	RED Digital Clip

RSX pre-grading file

Filename extension	.rsx
Container for	colour-correction information
Contained by	RED Digital Clip
Extended from	XML

R3D files, as generated by RED's digital cameras, have a symbolic naming convention whose aim is to both uniquely and unambiguously reference each clip/take which has ever been shot every day by each camera, as well as aiding during the online editing and post-production phases to discern which reel, camera and shooting date combinations that clip "belongs" to.

RED Digital Magazines

R3D files are first arranged into former-level folders, called RED Digital Magazines (RDMs); a RDM folder is created for each storage medium initialized (i.e. soft-formatted) and used by a RED digital camera and for every day of shooting (according to the camera's own internal clock). The RDM directory associated to camera (cam.) X (where X ranges from A to Z), equivalent of a traditional 3-digit reel number NNN, shot on the dd^th (2-digit) day of the mm^th (2-digit) month of any year is named X NNN_dd mm HH.RDM. In this case HH is just a hexadecimal hash code to make that clip universally unique.

RED Digital Clip

Inside each RDM, lower-level subfolders are generated for each take shot by the camera (i.e. sub-directory creation is triggered by the camera's record start/stop button): those are the RED Digital Clipss (RDCs). Takes are chronologically referenced by an increasing number within each RDM such that, apart from the hash code (which is RDM-independent), the TTT^th (3-digit) take from the above RDM is named X NNN_C TTT_dd mm HH.RDC.

R3D digital contents

Each take is stored in one R3D stream, by one or more R3D file with the same name as the RDC containing it, but with a .R3D file extension. Since R3D files are limited to a maximum size of 2GiB, upon reaching this limit, a new R3D file (with an appended _ppp tail for the ppp^th, 3-digit part) is generated within the same folder, whose contents are the raw continuation of the former one.

Other files

When using a RED One camera, the RDC folder always stores, apart from the R3D files of that specific take, four wrapper QuickTime files. These are just metadata containers without stream contents (they are a few kilobytes large) and must reside together with associated R3D file(s) in the same folder, otherwise they are useless. Once opened by a QuickTime Player utility with a R3D codec installed/binded, they point to the R3D file and allow normal playback of the latter file(s) as if they were normal compressed-video files. The four QuickTime proxies also automatically set the playback frame size to either full-resolution (_F filename suffix), halved, one-fourth or one-eighth resolutions (_H, _M and _P suffixes respectively).

There is no real need of these four QuickTime containers though, if the R3D files are to be processed by software natively supporting the REDCODE codec.

Other than that, additional files may be present inside a RDC folder, as generated by either the camera and intermediate software as well. Among these there might be content-indexing ASCII or XML files, as well as RSX files (same name as the RDC with .rsx extension), automatically generated by Red's proprietary software and keeping shooting-time and offline colour-correction / pre-grading information. Such metadata may be later used for either later previewing, offline editing and DI conforming.

R3D metadata file format specifications

Apart from the audio/video codec itself, which is proprietary and closed-source but made public via a SDK licensed by RED, some details about the container and metadata within R3D files generated by a Red One camera have been partially reverse-engineered by several, independent projects.

First of all, metadata are recorded at both the beginning and ending of the R3D data stream, that is as the file header in the first R3D file, as well as a file footer in the last R3D file making the stream.

The file format's magic number is "0₁₆0₁₆1₁₆DRED1", which also defines the beginning of the file header on the first R3D file. The stream tag "REO" marks the end of the whole R3D stream (the end of the clip recording, 52 bytes from the EOF), i.e. the file footer of the last R3D file. The header stores a priori information on the clip like camera/storage settings/serials, firmware versions, start TimeCodes (read below), plus frame-, audio- and file-format settings, including colorimetry as well as on-camera colour-correction parameters. The footer stores a fortiori information instead like, most notably, the overall clip duration in frames; from the latter and the knowledge of the record frame-rate, the clip's ending TimeCodes can be easily recovered.

A R3D file is internally organized into substreams, mainly containing small chunks of audio or video contents (as well as other metadata). These chunks are sequentially stored within the R3D file and initiated by specific tags (REDV for video chunks, REDA for audio chunks) for synchronization purposes during file playback. The initial video chunk in a R3D stream (the first REDV chunk in the first R3D file of a RDC) also happens to include the file header itself.

Most notable metadata are recovered at absolute positions within the header, according to this table (offsets are expressed in 0-based bytes from the start of the first R3D file):

Within the file header, each metadata starts with a 16-bit identifier, which is a "10₁₆" character followed by the metadata's ordinal number ("00₁₆" being the first one). Metadata are typically written in order, although not all are consecutively defined (e.g. those whose ID starts with "100₁₆" refer to TimeCode-based chrono-timing, those starting with "103₁₆" are information about recording media, and so on). This format is reminiscent of JPEG standard, used for both JFIF and Exif metadata encoding, as well as binary internal tagging used for TIFF file format's metadata.

Metadata are written as either plain ASCII strings, words, IEEE floating-point values, or other proprietary codings; strings can be either fixed- or variable-length (metadata IDs allow the header's elastic syntax), but they end in both cases with either a NULL ("00₁₆") byte or "000F₁₆".

The following table contains some of the reverse-engineered metadata within a R3D file header. First column contains the (decimal) metadata ID: for example, metadata ID #42 (hexadecimal "2A₁₆") is coded, within the file header, just after the string "102A₁₆".

From the file footer (i.e. the final part of the last R3D file of a clip) the number of frames can be simply recovered as being a word (16 bits) 30 bytes from EOF.

Workflow

A consequence of the Red's raw-based workflow is that footage must be processed through a demosaicing algorithm before it can be viewed. Red has provided a QuickTime component which allows a fast demosaic to occur in real time so the footage can be used in applications that support QuickTime without transcoding. Higher-quality output can be achieved by transcoding the footage through Red's RedCine-X or RedCine-X Pro desktop software. Using the Red Rocket card allows for real-time processing. Currently the QuickTime component is only available for Intel-based Mac OS X and not Windows.

Playing back the high-resolution 4K files directly is extremely processor-intensive and outside the capabilities of most current computers. However, since REDCODE is a wavelet codec, the files contain several lower resolution versions of the video; the codec uses each in sequence to build the next higher resolution version.^[1] That means a 4K file can supply 2K, 1K, or even 0.5K footage directly without decoding the full 4K resolution data followed by scaling. For QuickTime and other programs without support for this feature, reference movies can be made. These are small files without video data that contain pointers into the original video file. For example, in Final Cut Pro, one may import QuickTime reference files that only have pointers to the parts of the 4K file that contain the lower-resolution version. This way work is done with speedy low-resolution video without need for a separate low-resolution copy.

Application compatibility

Apple's Final Cut Pro can use REDCODE files (via Quicktime reference movies) when the Red QuickTime codecs are installed. Assimilate Scratch was one of the earliest applications to support the raw camera data off the natively generated REDCODE files, and has continued to do so ever since.

Adobe's video products (Premiere and After Effects) have been able to work with the native REDCODE files (.R3D file extension) as of version CS4, and the plug-ins to do so are officially supported by Red.

Sony's video editing product Vegas Pro can natively edit .R3D files as of version 9.0, and allows full access to raw decode metadata with real-time preview.

Autodesk's 2010 releases of Smoke and Flame have a tool, WireTap Central, that converts .R3D files into a native media form. The 2011 releases of Smoke and Flame have native R3D import.

Avid Media Composer v5 has native REDCODE support via AMA (Avid Media Access). AMA allows for the direct linking to the R3D files and immediate editing of the sources. Avid Media Composer also allows direction interaction on a per clip or batch process for the color metadata. RLS, RSX, and RMD files are all supported. The RedRocket card is also supported for accelerated transcoding of the R3D files into Avid DNxHD and other editing codecs.

Avid DS v10.1.1 has native REDCODE import and linking support. Avid also has a tool called MetaFuze that will convert .R3D files into a native Avid MXF files for use in Media Composer and Symphony (v4 and earlier). Media Composer v5 and Symphony v5 have AMA support for REDCODE, allowing for direct editing R3D media. Avid DS and MetaFuze also support use of the RedRocket card.

Eyeon Fusion v6.0 and later includes native .R3D support.

IFX Software's Piranha provides naitive support for .R3D since version 5.2, with no need to transcode internally. The RedRocket card is also supported for accelerated transcoding of the R3D files, facilitating all aspects of the software, including finishing and mastering.

Nuke 5.2v2 (The Foundry) includes updated .R3D support (SDK v2).

References

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (December 2007)

External links

• Red Digital Cinema Camera Company official website
• REDuser.net forum
• Official FFmpeg website