From Wikipedia, the free encyclopedia
Jump to: navigation, search
R3D file
R3D file icon
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 the Red Digital Cinema Camera Company and featuring lossy compression for video contents and lossless for audio contents.[1][2][3] 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.[4] 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 [5]) 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[edit]

Video streams within a R3D file are stored as a series of images, each independently compressed in the wavelet-based JPEG2000 format.[3] Each image has four channels (color planes), corresponding to the Bayer pattern of the sensor: 1 for red, 2 for green, 1 for blue.[2][3] 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.[2][3] 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.[6][7][8][9] 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.[10]

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

Naming convention[edit]

RED Digital Magazine (REDMag)
REDmag icon
Filename extension .RDM
Type of format Folder
Container for RED Digital Clips
RED Digital Clip
RED clip icon
Filename extension .RDC
Type of format Folder
Container for REDCODE RAW footage
Contained by RED Digital Magazine
R3D file icon
Filename extension .R3D, .MOV, .rsx
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[edit]

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 ddth (2-digit) day of the mmth (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[edit]

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 X NNN_C TTT_dd mm HH.RDC.

R3D digital contents[edit]

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.

Other files[edit]

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 (_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 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[edit]

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 "016016116DRED1", 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):

Offset Type Field name Description
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 YYYYmmdd format.
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 RED if a RED-proprietary storage).
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 FULL, 1.85, 2.35,16:9, etc.).

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,[11] while the newer Red Rocket-X processes files with resolutions of 6K.[12] 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.[13] 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,[14] Final Cut Pro X,[15] and Vegas Pro.[16]


  1. ^ "Overview of the REDCODE File Format". Red Digital Cinema Camera Company. 2012-10-03. Retrieved 2014-03-13. 
  2. ^ a b c "REDCode". MultimediaWiki. 2012-01-22. Retrieved 2014-03-13. 
  3. ^ a b c d Schlaile, Peter. "libredcode". Retrieved 2014-03-13. 
  4. ^ "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. 
  5. ^ Carter, Kevin. "RED Epic Dragon review: First camera to break the 100-point DxOMark sensor score barrier!". DXI Kabs. Retrieved 12 April 2014. 
  6. ^ H, Karl. "Epic compression in slo-mo". Retrieved 12 April 2014. 
  7. ^ Espinosa, Jose. "Very weird Epic artifacts". Retrieved 12 April 2014. 
  8. ^ Silakov, Konstantin. "Big problem - artifacts in the picture - red epic-x". Retrieved 12 April 2014. 
  9. ^ Jonas, Drehn-Knudsen. "Uncompressed vs REDCODE". Retrieved 12 April 2014. 
  10. ^ "Deconstructing RAW - Part II". Wolfcrow. Retrieved 12 April 2014. 
  11. ^ "RED ROCKET". Retrieved 2014-04-12. 
  12. ^ "RED ROCKET-X". Retrieved 2014-04-12. 
  13. ^ "Indie4K » QuickTime Redcode support explained". Retrieved 17 April 2009. 
  14. ^ "Red Workflow for Avid – The Complete Guide". Avid Screencast. Retrieved 12 April 2014. 
  15. ^ "Final Cut Pro X: Importing RED Media". Apple Support. Retrieved 12 April 2014. 
  16. ^ "Working with RED ONE Camera Files in Vegas Pro 10". Sony. 2010. Retrieved 12 April 2014. 

External links[edit]