Change Details

This task will go over improvements I want to suggest to the Draw Manager Colormanagement. This ticket is in discussion, in the hope to get viewpoints of other experts about the subject. The scope of this ticket is limited to the draw manager as there are some isolated issues here. When the design is completed we can create an engineering design on the how. **Current Situation** DrawManager is used in many areas with other target colorspace needs than currently available. DrawManager has a flag do_colormanagement, what can be on or off. When on it is up to the draw engines to do the correct expected actions for color management. Most of the time this has been implemented with a lot of assumptions and un-clarity about the colorspace the buffers are currently in. For example: * Workbench and Grease Pencil assumes that this flag can be used to detect how their input and output buffers needs to be handled (Linear vs sRGB). Both don't use the scene color management settings for this, but uses fix 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 Scene ref space. * Scene Strip: the draw manager will render workbench/eevee and greasepencil results are stored in an ImageBuffer. * Image Rendering: the draw manager will render workbench/eevee and greasepencil results is stored in an Image buffer in Scene ref space * PyAPI: opengl_render **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 linear. * When using a scene strip the buffer is not converted to sequencer, but to the sRGB. With the default settings these are the same, but when users change it... * Rendering greasepencil results in different results in the different modes. * Movieclips/Images as Camera Background Images/Image empties do not respect color management settings. * ... **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. * To be able to set a target OpenColorIO role, when drawing to an offscreen buffer. This will increase viewport rendering performance. * Make sure that when overlays are drawn, the input buffers are transferred to the expected color space (display), and transferred back afterwards.

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 Ccolor management. This ticket is in discussion, in the hope to get viewpoints of other experts about the subject. The scope of this ticket is limited to the draw manager as there are some isolated issues here. When the design is completed we can create an engineering design on the howAfter 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. what can be on or off.When its on, When on it is up to the draw engines to do the correct expected actions for color managementt actions. Most of the time this has been implemented with a lot of assumptions and un-clarity about theabout colorspace of the buffers are currently ininput and output. For example: * Workbench and, Grease Pencil assumes that this flag can be used to detect howthe colorspace of their input and output buffers needs to be handled (Linear(Rec709 vs sRGB). Both don't use the scene color management settings for this, but uses fixfixed 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 Scene ref spaceRec709. * 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 Scene ref spaceRec709. * PyAPI: opengl_renderrender.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 linearRec709. * When using a scene strip the buffer is not converted to sequencer, but to the sRGB. With the default settings these are the same, but when users change it... * Rendering greasepencil results in different results in the different modessituations. * 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. This will increase viewport rendering performancAt 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.