4.10 File Formats

There are an ever increasing number of file formats, many of which support a variety of encodings, so some common sense is needed when choosing between them. Usually, it is best to minimize transforms and conversions, so sticking to as few file formats as possible is generally best.

Given production, post-production, and delivery have very different requirements, they would justifiably have different file formats. Production and image capture need a file format with minimal compression and maximum information. For real-time capture write speeds are important and large file sizes are common. Post-production is more interested in moving and processing information than production, so there is some pressure to reduce the file size, but also to have easy read encoding. It is still important to preserve maximum information, but more efficient encodings are typical. XXX Delivery formats are mostly dictated by the end client and should match their archive and distribution architecture. Since many of the bigger organizations are heavily invested in their libraries and archives, changes to delivery formats are slower than in other areas. Storage and flexibility are the driving forces for distribution, so heavier compression and display referred files are most common. However, some companies are now asking for ungraded and/or scene-referred masters along with metadata for versioning. XXX

4.10.1 DPX

DPX is a SMPTE standardized image format that is commonly used in the motion-picture industry. While the DPX format supports a variety of pixel types including float32, it is most commonly associated with uncompressed 10 bit and 16 bit unsigned integer RGB imagery. Unlike EXR - which is synonymous with scene-referred linear colorimetry, DPX does not have a canonical color space. It is common for DPX to store any number of integer camera log encodings, in addition to broadcast-ready Rec. 709. Generally, if you’ve got a DPX file the only way to know for sure what you have is through communication with the person who created it, or detailed forensic analysis failing that. DPX has limited metadata support, including a few settings related to colorimetry, but beware these flags. Even under the best of intentions DPX metadata is rarely preserved for long.

4.10.2 EXR

OpenEXR is an open-source image format created by ILM in 1999, which has near universal adoption in the VFX and animation industries. OpenEXR is intended for storing floating point, scene-referred linear imagery. Although OpenEXR was not the first image format suitable for storing HDR float data, it is the most popular in film production due to its efficient lossless compression codecs, support for 16 bit half float pixel type and support for other features such as data window/display window tracking, multiple layers, deep frame buffers, rich metadata encoding, and the lack of legacy format baggage.

In our experience, the half data format is sufficient for color images, color channels being those viewed using tone rendering, examples of which include beauty renders, specular color, diffuse color, per-light color AOVs, etc. For data channels requiring high precision representations of physical attributes, such as depth, normals or control maps, full 32 bit float is available and often necessary.

The maximum value for float-16 is 65504.0f. The minimum positive value that can be represented without a decrease in numerical precision, is 6.1035e-05f. It is important to remember when dealing with floating-point data, that the bits are allocated very differently from integer encodings. Whereas integer encodings have a uniform allocation of bits over the entire coding space, the floating-point encodings have increased precision in the low end and decreased precision in the high end. Consequently, if one has an unsigned 16 bit integer image, converts to a float-16 representation, and then converts back, fewer than 16 bits of precision are maintained.

OpenEXR supports a variety of compression options. Piz (wavelet) probably offers the highest lossless compression ratio on grainy material but is relatively expensive computationally. The zip options offer a reasonable compression ratio on computer-generated elements and is less computationally intense. The b44 codec is lossy; intended for real-time playback. OpenEXR also can store a tiled, mipmapped representation, and is thus suitable for use as a renderer texture format. OpenEXR 2.0 added deep buffer support: an arbitrary number of depth-samples per pixels, at the expense of increased storage requirements.

Because image data stored in OpenEXR files is normally scene-referred linear, a viewing transform is required to display the image. Metadata can be included which specifies the primaries of the image data but as with DPX, this metadata should not be trusted in general. A naive transform to an output-referred space such as sRGB will clip any data above 1.0. As part of the ACES standardization effort, a constrained version of OpenEXR was specified in SMPTE as ST 2065-4:2013. This standard specifies the on-disk bit representation of image data and critical metadata. One of the metadata fields specified in ST 2065-4 is the "ACES Image Container" flag which is intended to indicate an OpenEXR image is a compliant ST 2065-4 file. ACES ST 2065-4 files are encoded as scene-referred linear images using the AP0 primaries and should be viewed through an ACES output transform. This ensures that anybody viewing the image sees it in a way which perceptually matches what any other viewer sees, independent of display or viewing environment. XXX