Application Settings¶

Here are some general tips to apply in all software.

For any application, you’ll need to find these four settings, if they’re available: color interpretation on imported files, workspace, display space, color space in exported files.

Import¶

Each time an image or video file is imported into the application, one must control, or define, the space used to interpret the color values coming from the file.

Generally:

• Uncolored data (such as normal maps, velocity, displacement map, z-depth, etc.) should be taken as is, in a mode often called raw or utility for example.

• For linear color values* (typically, colors in EXR files), one must always define the space in which they were previously worked (linear RGB, ACEScg, Filmic…) or deactivate the interpretation (raw or utility mode) and apply a LUT to the image, corresponding to the space, via an effect for example.

• For non-linear color values, in general the standard space for videos is Rec.709 (HD) or Rec.2020 (UHD, 4K and 8K), and sRGB for image formats (PNG, TGA…).

• For videos coming from cameras, the space may not be standard but a camera-specific space.

Workspace¶

All 3D renderers operate in linear space* with floating point* 32 bits per channel.

For professional 2D applications, one often have a choice of depth: integer* 8 or 16 bits per channel, or floating point 32 bits per channel. Start by defining this depth; as a general rule in compositing, prefer to work with floating point 32_bits per channel to never lose values that are too bright (overexposed*) and always be able to work on all colors (except in special cases or to improve performance). In drawing applications, this choice is less essential.

In this case, one can also choose to work on linear colors, rather for compositing, which allow a more natural color blending and lights without artifacts, without fringing in reduced opacities, or, in drawing, with a gamma* for a color blending closer to painting.

If the space uses floating point and linear values, then it will be necessary to choose how these color values are transformed to the display and output space, via a wide color space, such as ACEScg or Filmic, or another.

Display¶

To avoid any errors, the simplest thing is to clearly set the color space of the screen at all steps, generally sRGB. It’s possible, via proofing or simulation only, in the final stages of the production, to select the delivery space. But be careful, this is indeed a simulation, and especially not to select the delivery space as a display space! Not all software offer this type of simulation, which is of little use in video (although very useful in printing where the final printed spaces are very different, and the white areas depend on the color of the paper).

Export¶

Overall, the ideal output for a file intended to be re-used in another step is always the openEXR format, the only one able to keep all information, even floating point values, and also contain useful layers which aren’t the color data (like depth, velocity vectors, etc.). In this case, it’s during the import that one must be careful and re-apply the correct space when interpreting the file, but at the output no conversion must take place and the files store image raw data, without color space information.

For applications not working in a linear floating point space, you can output images in a standard, lossless format such as PNG which can contain 16 bits per channel (the maximum with integer values). In this case, colors are converted to the file’s standard space, usually sRGB; It’s also possible to use Rec.2020 in PNG files, which makes it a good format for work intended to UHD, 4K or 8K videos, and cinema, but be careful in this case with the interpretation when importing the files!

For final output and in the absence of information from the broadcaster, or for general distribution for example on the internet, one should use the most standard space possible: Rec.709 in HD video, Rec.2020 in UHD video, sRGB in still images.

A word about video editing¶

In video editing, two approaches are possible. At its simplest, when importing media into the application, pay attention to the interpretation of the colors during the import (which is sometimes surprisingly complicated on certain editing software, or even completely absent), and export in the format and the color space of the delivery. The problem is that editing software isn’t really designed to respect the color production pipeline and that one generally doesn’t have any control over their workspace or even output color space and the types of values used. There is always the risk of losing information and quality.

Thus, as far as possible, prefer the second, historical approach: editing is done on proxies whose quality matters little, but the final export, the conformation, is done from the original media (possibly via another dedicated software or that which will be used for color correction after editing, generally using an export of the edit in XML format).