📜 ⬆️ ⬇️

OpenColorIO and Krita: processing and drawing HDR images

Images with a wide dynamic range will not surprise anyone. Probably everyone at least once in his life tried to create an HDR photo. However, few people know that in the film industry this technology has been used for more than ten years, and all the working processes of the pipeline, starting from the creation of textures and ending with the rendering of the finished scene, are closely related to working in linear color spaces represented by floating-point numbers.

In this article I will try to tell you what scene-oriented color management workflow is, why you need the OpenColorIO library, and how to set up work in the OpenColorIO environment in a free graphic editor for artists Krita.

What is OpenColorIO?


OpenColorIO (OCIO) is a library providing work with color in the film industry. In particular, it was used to create Spiderman 2 (2004) and Alice in Wonderland (2010) films. OpenColorIO is designed to convert all color spaces that are encountered as the image moves along the conveyor.

Example. The texturizer created the texture in sRGB color space, 8-bits per channel. When moving further along the pipeline, the texture gets to the modeller, which, to impose it on the model, translates it into a linear RGB, 16-bit floating point. The scene is rendered again in linear RGB, 32-bit floating point, and the final result is transferred back to sRGB8 so that it can be shown on a standard monitor.

For thought at your leisure
Why should texture be transferred to a linear color space before applying a texture to a model and, in particular, before generating mipmaps (MIP pyramids)? What threatens sRGB?

It is obvious that all these transformations should be described somehow. Moreover, it is desirable that they are described centrally, because not just a few people can work on one film, but several teams or even companies, each with its own rules and standards. This task is exactly solved by OpenColorIO.
')
All parameters of the workflow in OpenColorIO determines the so-called. configuration, which is usually just a directory with a text file config.ocio and color conversion table files (look-up table, LUT). The configuration file describes all conversions between the color spaces used in the pipeline. So, in order to ensure uniform work with color for all performers, it will be enough to send them this configuration and ask them to write the path to it in the $OCIO environment variable. All OCIO-enabled applications will read this variable and automatically use the correct settings.

Examples of configurations can be found on the official website .

Why not ICC?


Many have probably already wondered why this OpenColorIO is needed when there is an ICC-profile mechanism standardized by the International Color Consortium?
Many, many technical details for those interested.
Yes, indeed, ICC profiles solve a similar problem. They also describe how to transform color from space A to space B. But they have one feature: all connections in them are made through absolute spaces L * a * b or CIE XYZ. This was done on purpose. When using ICC profiles, the user wants his image to look the same on all output devices. And most likely, the user does not have access to the devices themselves. They may be at the other end of the street (city, country or globe), but the image should still look the same. In this case, without reference to the reference color spaces can not do.

In the case of the process of creating a movie, everything looks slightly different. The task of linking various output devices is relegated to the background (with profiling monitors in a professional studio, they can do it somehow), but a new requirement appears: the transformations must take place without loss. Moreover, for them there should be inverse transformations, which also do not lead to distortions. Indeed, consider a simple example. After scanning from the film, we get the file in a logarithmic color space, then convert it to linear to perform compositing, and then use the inverse transform with a power of 2.2 to display on the monitor. It is obvious that with such transformations, errors in highlights by 1 bit (244 <-> 255) after applying the power function will lead to clearly visible artifacts when viewed.

This is where OpenColorIO comes to the scene with its centralization. All color spaces with which they will work at each stage of film making are projected prior to the start of works. The transformations between them are chosen one-to-one so that the image can move without loss both along the conveyor and in the opposite direction. These transformations are set directly, without using the bindings to the reference spaces L * a * b or CIE XYZ, which would instantly introduce many problems (at least, constant conversion of the white point value back and forth, for L * a * b and CIE XYZ) standard - D50). So the transformations in OpenColorIO are easier and are often described by simple mathematical expressions.

Thus, the ready configuration of OpenColorIO defines a closed set of color spaces in which performers can work and is guaranteed to get a quality result. In some ways, the lesser versatility and complexity of adding a new space acts as a limiter and shields performers from using untested color spaces.

To some extent, OpenColorIO belongs to a lower level of abstractions than the ICC, just like the assembler is below the high-level languages. Similarly, the artist, using OpenColoIO, gets much more features that are not available in high-level tools. Of course, at the price of great knowledge and some complication of the concepts used.

Scene-referred vs. output-referred workflow


Most people are accustomed to assume that ICC-profiles and this whole idea with color management is only needed in order to correctly output the file to a printer (minilab, a print shop). In general, they are right. Such a workflow, when a file is being prepared for a particular output device, is usually called device-oriented (output-referred workflow). However, what to do if your picture will eventually be displayed on a variety of media? For example, a scene from the film will be displayed at least on a monitor, projector and film. Each device has its own characteristics, its own gamma and its dynamic range. What workspace to choose and how to work with it?

To solve this problem, when making films we went another way. All work takes place in a linear RGB space with an unlimited dynamic range (RGB channel values ​​can easily exceed 1.0). Rendering, generation of special effects, everything happens in this artificial space, and only at the final stage of the project, when you need to display an image on a specific device, it is brought to the standard range 0.0 ... 1.0 (compressed or cropped) and sent to the device. Such working process is called scene-oriented (scene-referred).

Opportunities Kryta to work with color


Crete supports work in both device-oriented and scene-oriented workflow. At the same time, it supports both ICC profiles and global settings of OpenColorIO. Next, consider both options for setting up Kryta.

Connecting monitor calibration and profiling data to Crete (ICC profile)

When OCIO is disabled or when OCIO is operating in the Internal mode, it uses the ICC profile specified in the settings (or received from the X server) to render the image on the Crete screen. To get accurate color reproduction, you need to follow a few simple steps:

  1. Calibrate the monitor and build its profile. Under Linux, this can be done using dispcalGUI (tested with X-Rite i1Display 2). An ICC profile will be output on output.
  2. Download the VCGT-tag (Video Card Gamma Table) stored in the ICC profile in the LUT of the video card. Under Linux, this can be done with xcalib or dispwin . Under Windows, just select it in the system settings. At this stage, the monitor will become calibrated, but the profiling data will not be active yet.
  3. Select a monitor profile in Crete Preferences->Color Management : Preferences->Color Management .

Now the color of all images will be displayed correctly.

Creating an OpenColorIO configuration with monitor profile data

One of the advantages of OpenColorIO for us is that when using it, it becomes possible to transfer the calculations related to color to the GPU, thereby significantly speeding up the rendering. Far from the fact that ordinary users will need to create and describe their own color spaces, but the acceleration of work will need exactly. As an example, we will create a configuration that will take into account data on monitor profiling.

Working with OpenColorIO is somewhat more complicated than with ICC, since you need to explicitly create a transform for each input color space that we will use. Create a transformation that converts colors from sRGB to monitor space.

To do this, we need to create a 3D LUT table for this conversion. In dispcalGUI select Tools->Create 3D LUT , select sRGB as the source space, and select the monitor's ICC profile as the target space. The resulting file is saved in the luts subdirectory of the test configuration under the name srgb_to_monitor.3dl . Now, when this configuration is activated, the color space of the image will be transformed into the monitor space by means of OpenColorIO. If openGL mode is active, then all calculations will be performed on the GPU.

Drawing HDR images in Crete


A regular monitor is clearly not a HDR device, so special tricks are used to display and edit a file with a wide dynamic range. The artist, working with the work, can choose which part of the range he wants to work with at the moment. To do this, it has and - settings, which are applied only when rendering on the display and have no effect on the data stored in the file. A change in exposure compresses or, on the contrary, stretches the range, and a change in the gamma value changes the steepness of the conversion curve. You can change the current exposure value with a simple gesture: to do this, just hold down the 'Y' key and drag the mouse over the canvas. Exposure will change dynamically. A similar gesture can be assigned to change the gamma.

A special feature of Kryta is that it contains tools for choosing colors in the course of all the transformations that occur with an image before it is drawn on the display. Therefore, colors in the color selection panels are displayed exactly as they will appear when drawing, whatever the settings for the exposure, gamma and color spaces at the moment. Moreover, when changing the display settings, Crete will try to adjust the current drawing color so that with the new settings it looks exactly the same as the previous ones, and the user can continue drawing with the same color. This is not always possible, because often the conversion to the color space of the monitor is irreversible. In such cases, when you change the exposure and gamma settings, you will see how the current selected color changes slightly.

Thus, Crete allows you to draw an image without in any way thinking about the current exposure value. Just change the current range with a gesture and draw.

Bonus for those who read to the end:

HDR landscape from Wolthera van Hövell tot Westerflier


HDR scene from Timothée Giet


Instead of conclusion


In this article I tried to tell you what methods of working with images used in the film industry and what functionality to support these processes offers Crete.
This functionality was added to the main branch quite recently and many things need improvement in terms of user experience. We are working on it and accept any suggestions on this matter.

Source: https://habr.com/ru/post/227597/


All Articles