Common mistakes and misunderstandings, Trouble­shooting¶

Common mistakes¶

The workspace must be the same as the file to be delivered.¶

This isn’t true: when working and computing colors, it’s necessary to work in a space “larger” than the delivery; indeed, the precision during calculations must be greater than that of the data to obtain. To be able to work in a larger space, as well in gamut* as in depth* guarantees a better respect of the colors when exporting.

If the workspace isn’t larger than the output workspace, artifacts may appear, such as banding, the appearance of visible bands in fine gradients.

If the workspace is linear, its depth must also be greater than that of the output workspace, and this is in any case recommended even for a non-linear workspace. Thus, for an 8 bpc output, it is preferable to work at least in 16 bpc, or in 32 bpc for a 16 bpc output.

It’s equally false to believe that working in a larger space will mqke you select and use colors “outside” the output format. See the next question.

Working in a color space larger than the output color space is dangerous because we might choose colors that cannot be reproduced.¶

This isn’t true: even if the workspace is very large (such as ACEScg for example), the colors displayed by the screen are the result of a “live” conversion to the screen space, which is necessarily smaller (sRGB in most cases). It’s impossible to have variation at the time of the export, which will undergo exactly the same transformation.

It should be noted that the majority of screens (except HDR and other screens in P3) cannot display the colors used in HDR and cinema; the problem is thus rather opposite: how to work on colors outside of the display space of the screen…

However, what’s true is that one must be careful in the selection of colors in rendering engines (3D): the colors chosen on the screen are colors displayed in sRGB, and it’s easy to select colors that are too intense or too saturated without realizing it, because they’re actually outside the sRGB space in values. One way to overcome this problem is to make sure that the color pickers of the application are limited to sRGB values for example (the application taking care of the conversion from sRGB to the workspace); in this case, the selection of an intense green for example will still be far from the extremes of the larger workspace, and the color will not risk to brighten and saturate the scene too much.

We must choose a Rec.709 display space because the video output will be Rec.709.¶

This isn’t true: the display color space must be that of the connected screen (sRGB in most cases in computing).

This display space is used for conversions from the workspace to the screen space.

When the video file is exported, a conversion is made from the workspace to the video space, Rec.709 in this example. And it’s when the video is played that a new conversion takes place again from the Rec.709 to the sRGB space of the screen.

Troubleshooting¶

When playing a video, the colors aren’t the same as in the software that was used to create it.¶

Here are the parameters to check:

1. Display issue in the application: the display color space in the application must match that of the screen (sRGB most often).
2. Output issue: the color space of the output video isn’t standard; check the space used in the application output settings.
3. Playback issue: the video playback is badly configured in the graphics card settings (see below When a video is played on the computer (…) the colors appear “dull”.)

If a (very slight) variation persists, it may be due to the conversion from RGB to YUV, or the compression of the video format. In this case, there is nothing to do…

“Banding”: colored “bands” appear in the fine gradients.¶

Most often, this problem comes from the fact that the application working color space is too small and the depth* is too small compared to the output format.

Here is what to check and what can fix the issue:

• The color depth in the application should be higher than the output (16 bpc minimum to output in 8 bpc, etc.), especially if the working space is linear.
• If it’s not possible to increase the depth of the working space, a space with the same gamma* as the output one can help reduce the problem.
• Choose a working space with a wider gamut* than the output space.
• If the gradient is part of an imported file, check the above points in the application that created the file.
• Banding problems may occur due to compression; check if they’re still visible in lossless formats (openEXR, PNG, Quicktime Animation, etc.)
• Adding a very slight, imperceptible noise or grain to the image often “fixes” this issue.

A fringe, a blurred line, appears in colored or high contrast areas, especially on vertical or horizontal lines.¶

This problem is usually a consequence of chroma subsampling, when switching from RGB to YUV. If possible, increase the subsampling (4:4:4 or 4:2:2 instead of 4:2:0 for example). If this isn’t possible, and the image is a still image, it’s sometimes possible to move the image a pixel or two in the video to correct the problem.

When playing a video on a computer, in most players and on videos on websites, the colors look “dull”. Whites are light gray, blacks are dark gray.¶

There is probably a conversion error from the Full to the Limited range or vice versa.

In the parameters of the graphics card, a “video” option often allows to change this setting; you have to choose Full/PC range if it’s a computer screen that is connected, or Limited/TV range if it’s a TV.