Overview of the impact on the code-base

After discussion we need to clarify the next points:

• EEVEE/Workbench and Grease Pencil can use linear_to_srgb encoding. This has nothing to do with color management, but to reduce vram usage during rendering. This part needs to be more explicit as it confuses experts and developers. It was suggested to refactor this bit and add documentation of the mechanism.
• When selecting other color management settings the linear to srgb encoding also needs to be configured. otherwise to much information can be destroyed.
• As we convert to display space later in the pipeline the intermediate buffers also needs to be increased. The idea is to start with RGBA16F for most buffers and limit buffers that can use with less.
• Related to the previous point. We could provide user option to select the desired bitdepth (rgba8, rgba16f or if possible rgb101210

Step 1: Minimum changes

OCIO C-API

It should be possible to only do the view transform. or only do the display transform.

DrawManager

draw/intern

• Add an UBO containing the references to the LUTs with most common transforms.
• rename DRW_state_do_color_management to DRW_state_do_display_transform.
• Split DRW_transform_to_display into DRW_transform_to_display and DRW_transform_to_view.
• Convert all colors in GlobalsUboStorage to scene reference space when created (use: IMB_colormanagement_srgb_to_scene_linear_v3).

draw/engines/overlay

• Draw Image Empties and camera images in scene reference space.

Cycles

Add an option to skip the view and display transform when drawing to a glsl buffer.

Limitations

weight colors: Weight colors are currently created and interpreted in sRGB on the fly and used in multiple shaders. We could add the color conversion in the vertex shader and do the interpolation in scene reference space.
vertex colors: vertex colors are stored in sRGB. Should we convert the vcol buffer to scene reference space so all colors in the draw engine are expected to be in scene ref space. This has performance impact as this is done on the CPU.

Converting the vertex colors on the GPU will impact rendering performance. Due to this reason I would propose to do all the att%d_is_srgb=true conversions on the CPU.

Step 2: Support additional OCIO LUTS

For the draw engines it doesn't seem necessary to add ocio luts to the common_colormanagement_lib as everything will be rendered in the same space. The only exception are weights. If that is the case we need to change the ocio c-api. This is also a requirement when we want to implement the image and uv editor in the draw manager. Not having this would mean to many color conversions will happen when painting on an image.

OCIO C-API

release/datafiles/colormanagement/config.ocio

Perhaps no impact as sRGB is already a defined color space. Perhaps we need to add an sRGB role to do the shader generation.

intern/opencolorio

Add support to generate a part of a GLSL shader source that can be included in common_colormanagement_lib.glsl. including all the luts needed.

DrawManager

draw/intern

• Add an UBO containing the references to the LUTs with most common transforms. This UBO should only be attached when the common_colormanagement_lib is used. as it can contain textures and we don't want to flood the texture slots of OpenGL.