Change Details

This task will go over improvements I want to suggest to the Draw Manager color management. This ticket is in discussion, in the hope to get viewpoints of experts about the subject. The scope of this ticket is limited to the draw manager as there are some isolated issues here. After the design is approved, the engineering plan can be written. In the engineering plan we will go on the how and code-technical implications. **Current Situation** DrawManager is used in many areas with other target colorspace needs than currently available. DrawManager has a flag `do_colormanagement`, what can either be on or off. When its on, it is up to the draw engines to do the correct expected color management actions. Most of the time this has been implemented with a lot of assumptions about colorspace of the input and output. For example: * Workbench, Grease Pencil assumes that this flag can be used to detect the colorspace of the input and output buffers (Rec709 vs sRGB). Both don't use the scene color management settings for this, but fixed transform functions. * Overlay engines assumes that their input and output is always in sRGB. Usages of DrawManager * Drawing of the 3d viewport to the display: the draw manager will render workbench, eevee, greasepencil, external render engines and additional overlays directly to the device output. * Viewport rendering: The draw manager will render workbench, eevee, greasepencil, external render engines and additional overlays to an render result. results are stored in Rec709. * Scene Strip: the draw manager will render workbench/eevee and greasepencil results are stored in an ImageBuffer in (sRGB during editing, during final rendering the Image Rendering is used). * Image Rendering: the draw manager will render workbench/eevee and greasepencil results is stored in an Image buffer in Rec709. * PyAPI: render.opengl **Issues** * When doing viewport rendering the color management is done on the CPU what is typically slow. * When doing viewport rendering the overlay engine assumes that the input/output buffers are sRGB, but in fact they aren't, they are still scene Rec709. * When using a scene strip the buffer is not converted to sequencer, but to sRGB. With the default settings these are the same, but when users change it... * Rendering greasepencil results in different results in the different situations. * Movieclips/Images as Camera Background Images/Image empties do not respect color management settings of the image. They assume (as all overlay engines) that they input/output is in sRGB and are only able to handle Rec709 and sRGB images/movieclips. * ... **Proposal** * Generated GLSL color transfer functions by OpenColorIO configuration. `common_colormanagement_lib.glsl`. Make the functions OpenColorIO role based. this way it is more clear what function to use in what situation. The role based approach would also limit the configurations that needs to be handled by the shader. But some color management pre-processing needs to be done when images are not using a space defined by the role there in. * To be able to set a target OpenColorIO role, when drawing to an offscreen buffer. At the end of the drawing the offscreen buffer is then converted to the ColorSpace that is in the colormanagement configuration for that specific Role. * Make sure that when overlays are drawn, the input buffers are transferred to the expected color space (display), and transferred back afterwards. Note that color transfers are not reversible and that leads to other artifacts. This part still needs more thought.

This task will go over improvements I want to suggest to the Draw Manager color management. This ticket is in discussion, in the hope to get viewpoints of experts about the subject. The scope of this ticket is limited to the draw manager as there are some isolated issues here. After the design is approved, the engineering plan can be written. In the engineering plan we will go on the how and code-technical implications. **Current Situation** DrawManager is used in many areas with other target colorspace needs than currently available. DrawManager has a flag `do_colormanagement`, what can either be on or off. When its on, it is up to the draw engines to do the correct expected color management actions. Most of the time this has been implemented with a lot of assumptions about colorspace of the input and output. For example: * Workbench, Grease Pencil assumes that this flag can be used to detect the colorspace of the input and output buffers (Rec709 vs sRGB). Both don't use the scene color management settings for this, but fixed transform functions. * Overlay engines assumes that their input and output is always in sRGB. Usages of DrawManager * Drawing of the 3d viewport to the display: the draw manager will render workbench, eevee, greasepencil, external render engines and additional overlays directly to the device output. * Viewport rendering: The draw manager will render workbench, eevee, greasepencil, external render engines and additional overlays to an render result. results are stored in Rec709. * Scene Strip: the draw manager will render workbench/eevee and greasepencil results are stored in an ImageBuffer in (sRGB during editing, during final rendering the Image Rendering is used). * Image Rendering: the draw manager will render workbench/eevee and greasepencil results is stored in an Image buffer in Rec709. * PyAPI: render.opengl **Issues** * When doing viewport rendering the color management is done on the CPU what is typically slow. * When doing viewport rendering the overlay engine assumes that the input/output buffers are sRGB, but in fact they aren't, they are still scene Rec709. * When using a scene strip the buffer is not converted to sequencer, but to sRGB. With the default settings these are the same, but when users change it... * Rendering greasepencil results in different results in the different situations. * Movieclips/Images as Camera Background Images/Image empties do not respect color management settings of the image. They assume (as all overlay engines) that they input/output is in sRGB and are only able to handle Rec709 and sRGB images/movieclips. * ... **Proposal** * Generated GLSL color transfer functions by OpenColorIO configuration. `common_colormanagement_lib.glsl`. Make the functions OpenColorIO role based. this way it is more clear what function to use in what situation. The role based approach would also limit the configurations that needs to be handled by the shader. But some color management pre-processing needs to be done when images are not using a space defined by the role there in. * To be able to set a target OpenColorIO role, when drawing to an offscreen buffer. At the end of the drawing the offscreen buffer is then converted to the ColorSpace that is in the colormanagement configuration for that specific Role. * When rendering and compositing the linear scene ref space (default REC709) must be used. This means that the overlay/mode engines will be drawing in REC709 and only as a last step the view transform will be applied. ** Note that this will also impact how Grease pencil blends colors and there will be rendering differences. These differences are currently also noticeable during final rendering of GP projects. ** Images that are rendered in the background are currently fixed to REC709 or sRGB. other colorspaces are ignored. We should transform the image buffer from its color space to one of them (depends a bit on use). * Make sure that when overlays are drawn, the input buffers are transferred to the expected color space (display), and transferred back afterwards. Note that color transfers are not reversible and that leads to other artifacts. This part still needs more thought.

This task will go over improvements I want to suggest to the Draw Manager color management. This ticket is in discussion, in the hope to get viewpoints of experts about the subject. The scope of this ticket is limited to the draw manager as there are some isolated issues here. After the design is approved, the engineering plan can be written. In the engineering plan we will go on the how and code-technical implications. **Current Situation** DrawManager is used in many areas with other target colorspace needs than currently available. DrawManager has a flag `do_colormanagement`, what can either be on or off. When its on, it is up to the draw engines to do the correct expected color management actions. Most of the time this has been implemented with a lot of assumptions about colorspace of the input and output. For example: * Workbench, Grease Pencil assumes that this flag can be used to detect the colorspace of the input and output buffers (Rec709 vs sRGB). Both don't use the scene color management settings for this, but fixed transform functions. * Overlay engines assumes that their input and output is always in sRGB. Usages of DrawManager * Drawing of the 3d viewport to the display: the draw manager will render workbench, eevee, greasepencil, external render engines and additional overlays directly to the device output. * Viewport rendering: The draw manager will render workbench, eevee, greasepencil, external render engines and additional overlays to an render result. results are stored in Rec709. * Scene Strip: the draw manager will render workbench/eevee and greasepencil results are stored in an ImageBuffer in (sRGB during editing, during final rendering the Image Rendering is used). * Image Rendering: the draw manager will render workbench/eevee and greasepencil results is stored in an Image buffer in Rec709. * PyAPI: render.opengl **Issues** * When doing viewport rendering the color management is done on the CPU what is typically slow. * When doing viewport rendering the overlay engine assumes that the input/output buffers are sRGB, but in fact they aren't, they are still scene Rec709. * When using a scene strip the buffer is not converted to sequencer, but to sRGB. With the default settings these are the same, but when users change it... * Rendering greasepencil results in different results in the different situations. * Movieclips/Images as Camera Background Images/Image empties do not respect color management settings of the image. They assume (as all overlay engines) that they input/output is in sRGB and are only able to handle Rec709 and sRGB images/movieclips. * ... **Proposal** * Generated GLSL color transfer functions by OpenColorIO configuration. `common_colormanagement_lib.glsl`. Make the functions OpenColorIO role based. this way it is more clear what function to use in what situation. The role based approach would also limit the configurations that needs to be handled by the shader. But some color management pre-processing needs to be done when images are not using a space defined by the role there in. * To be able to set a target OpenColorIO role, when drawing to an offscreen buffer. At the end of the drawing the offscreen buffer is then converted to the ColorSpace that is in the colormanagement configuration for that specific Role. * When rendering and compositing the linear scene ref space (default REC709) must be used. This means that the overlay/mode engines will be drawing in REC709 and only as a last step the view transform will be applied. ** Note that this will also impact how Grease pencil blends colors and there will be rendering differences. These differences are currently also noticeable during final rendering of GP projects. ** Images that are rendered in the background are currently fixed to REC709 or sRGB. other colorspaces are ignored. We should transform the image buffer from its color space to one of them (depends a bit on use). * Make sure that when overlays are drawn, the input buffers are transferred to the expected color space (display), and transferred back afterwards. Note that color transfers are not reversible and that leads to other artifacts. This part still needs more thought.