|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 the 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.
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.
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.
|Type of format||Folder|
|Container for||RED Digital Clips|
|Type of format||Folder|
|Container for||REDCODE RAW footage|
|Contained by||RED Digital Magazine|
|Container for||audio/video + metadata|
|Contained by||RED Digital Clip|
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 ranges from
Z), equivalent of a traditional 3-digit reel number
NNN, shot on the
ddth (2-digit) day of the
mmth (2-digit) month of any year is named
.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
TTTth (3-digit) take from the above RDM is named
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
pppth, 3-digit part) is generated within the same folder, whose contents are the raw continuation of the former one.
When using a RED ONE camera, the RDC folder always stores, apart from the R3D files of that specific take, four QuickTime files. These are just metadata containers without stream contents (they are a few kilobytes in size) and must accompany their 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 though 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 (
_P suffixes respectively).
There is no real need of these four QuickTime containers though, if the R3D files are to be processed by software which natively supports the REDCODE codec.
Additional files may be present inside a RDC folder, as generated by the camera or intermediate software. Among these may be content-indexing ASCII or XML files, as well as RSX files (same name as the RDC with a
.rsx extension), auto-generated by Red's proprietary software and which contain shooting-time and offline colour-correction / pre-grading information. Such metadata may be used later for 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 "016016116
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):
|14||Word||Sample rate||Rate of audio samples (Hz)|
|54||Word||Width||Clip's original frame width (pixels)|
|60||Word||Height||Clip's original frame height (pixels)|
|62||Word||Framerate's # of frames||Read next field|
|66||Word||Framerate's # of seconds||Framerate being measured in frames per second, it is computable dividing the above field by this one.|
|67||32 bytes||Filename||Original R3D file name as created by the camera.|
Within the file header, each metadata starts with a 16-bit identifier, which is a "1016" character followed by the metadata's ordinal number ("0016" being the first one). Metadata are typically written in order, although not all are consecutively defined (e.g. those whose ID starts with "10016" refer to TimeCode-based chrono-timing, those starting with "10316" 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 ("0016") byte or "000F16".
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 "2A16") is coded, within the file header, just after the string "102A16".
|Metadata ID||Length||Field name||Description|
|0||11 bytes||Start EdgeCode||Start EdgeCode, i.e. clip TimeCode, as hh:mm:ss:ff|
|1||11 bytes||Start TimeCode||Start Time-of-Day TimeCode (ToD) of the clip, as hh:mm:ss:ff|
|2||14 bytes||Date #1||Auxiliary date, coded as YYYY_MM_DD_timezone|
|3||14 bytes||Date #2||Auxiliary date (as ID #2)|
|4||14 bytes||Date #3||Auxiliary date (as ID #2)|
|5||14 bytes||Record date/time||Record date and time, coded as YYYYMMDDhhmmss|
|6||8 + 24 bytes||Camera model + S/N||Camera model name + serial number|
|25||1 byte||Camera number||Camera abbreviated name (ASCII A through Z)|
|26||3 bytes||Reel number||Digital Reel (REDMag) number as 1-based, 3-digit string|
|26||3 bytes||Reel number||Take/clip number within a REDMag, as 1-based, 3-digit string|
|35||8 bytes||Original shooting date||Original shooting date in
|36||6 bytes||Original shooting time||Original shooting time in HHMMSS format.|
|37||variable||Camera firmware||Camera firmware string, usually coded in major/minor/revision/Build hierarchy, as MM.m.R#BB (Build being usually the firmware's major version).|
|41||11 bytes||Reel-start ToD TimeCode||Starting ToD TimeCode of the REDMag, coded as hh:mm:ss:ff.|
|42||16 bytes||Storage name||Storage medium Name (should begin with
|48||8 bytes||Storage up-date||Date in which the storage medium (REDMag) was formatted or re-initialized, coded as YYYYMMDD.|
|49||6 bytes||Storage up-time||ToD in which the storage medium (REDMag) was formatted or re-initialized, coded as hhmmss.|
|50||20 bytes (?)||Storage S/N||Storage medium Serial Number.|
|51||10 bytes (?)||Storage Model||Storage medium Model.|
|54||variable||Aspect ratio||Name of the frame's aspect ratio (either
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 the end-of-file marker.
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. 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.
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.
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
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).
Apple's Final Cut Pro X can natively edit .R3D as of version 10.0.6.
|This section needs additional citations for verification. (December 2007)|
- "Indie4K » QuickTime Redcode support explained". Retrieved 17 April 2009.
- Overview of the REDCODE File Format
- Official Red Digital Cinema Camera Company website
- REDuser.net forum
- Official FFmpeg website