|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, though RED promised a module in 2012 that would record proxies in other formats. 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 (though it's important to note that RED cameras record one ISO natively, while other ISO speeds are achieved through digital manipulation, whether in camera or in post ) 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 as a series of images, each independently compressed in the wavelet-based JPEG2000 format. Each image has four channels (color planes), corresponding to the Bayer pattern of the sensor: 1 for red, 2 for green, 1 for blue. Each frame is compressed to the same size, i.e. the video is coded with a constant bit-rate, and without dependencies on other frames, i.e. only intraframe compression is used.
In the Bayer pattern of the sensor, each group of four sensor elements captures 1 red pixel, 2 green pixels, and 1 blue pixel. Grouping the red pixels together, the blue pixels together, and half of the green pixels together yields four color planes, each with a quarter of the resolution of the sensor. These four planes are coded using the JPEG2000 algorithm. For that reason, R3D is a raw image format for video. A similar file format (or wrapper) is the Adobe CinemaDNG, or ArriRAW.
Decoding to RGB consists of two steps: decompression of the JPEG2000 data, followed by demosaicing. The demosaicing algorithm interpolates the four quarter-resolution color planes, corresponding to the Bayer pattern, to three full-resolution color planes, 1 red, 1 green, and 1 blue.
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 compression 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, though the amount of compression in these "raw" codecs is still debatable.
Audio streams (mono, stereo or 4-channels) are coded, uncompressed, in plain 48 kHz, 24-bit PCM.
|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 for files up to a 4K resolution size, while the newer Red Rocket-X processes files with resolutions of 6K. Currently the QuickTime component is only available for Intel-based Mac OS X and not Windows or Linux.
Playing back the high-resolution 6K, 5K, or 4K (depending on the camera and sensor) 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, for example, 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. REDCODE files can be used through a number of methods with most editing platforms such as Premiere, Avid Media Composer, Final Cut Pro X, and Vegas Pro.
- "Overview of the REDCODE File Format". Red Digital Cinema Camera Company. 2012-10-03. Retrieved 2014-03-13.
- "REDCode". MultimediaWiki. 2012-01-22. Retrieved 2014-03-13.
- Schlaile, Peter. "libredcode". Retrieved 2014-03-13.
- "RED EPIC and SCARLET to Get ProRes*, DNxHD, and H.264 Recording Through New Module". No Film School. 2012-09-20. Retrieved 2014-04-12.
- Carter, Kevin. "RED Epic Dragon review: First camera to break the 100-point DxOMark sensor score barrier!". DXI Kabs. Retrieved 12 April 2014.
- H, Karl. "Epic compression in slo-mo". REDUser.net. Retrieved 12 April 2014.
- Espinosa, Jose. "Very weird Epic artifacts". REDUser.net. Retrieved 12 April 2014.
- Silakov, Konstantin. "Big problem - artifacts in the picture - red epic-x". REDUser.net. Retrieved 12 April 2014.
- Jonas, Drehn-Knudsen. "Uncompressed vs REDCODE". REDUser.net. Retrieved 12 April 2014.
- "Deconstructing RAW - Part II". Wolfcrow. Retrieved 12 April 2014.
- "RED ROCKET". Red.com. Retrieved 2014-04-12.
- "RED ROCKET-X". Red.com. Retrieved 2014-04-12.
- "Indie4K » QuickTime Redcode support explained". Retrieved 17 April 2009.
- "Red Workflow for Avid – The Complete Guide". Avid Screencast. Retrieved 12 April 2014.
- "Final Cut Pro X: Importing RED Media". Apple Support. Retrieved 12 April 2014.
- "Working with RED ONE Camera Files in Vegas Pro 10". Sony. 2010. Retrieved 12 April 2014.
- Overview of the REDCODE File Format
- Official Red Digital Cinema Camera Company website
- REDuser.net forum