Double post processing frames with color management, when animation rendered #79999

New Issue

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87

Blender Version
Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-17 19:04, hash: e157573fab
Worked: (newest version of Blender that worked as expected)

Short description of error
For example increase gamma to 1.5 and render single image from viewport and single frame-animation from viewport.
For the second you will have 1.5 gamma applied twice. The same for filmic or other color management/correction

How it should be (similar result)

And how it looks (1 frame animation render on the right)

Full demo
2020-08-22_04-07-41.mp4

File
double post processing.blend

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87 **Blender Version** Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-17 19:04, hash: `e157573fab` Worked: (newest version of Blender that worked as expected) **Short description of error** For example increase gamma to 1.5 and render single image from viewport and single frame-animation from viewport. For the second you will have 1.5 gamma applied twice. The same for filmic or other color management/correction How it should be (similar result) ![49464312.png](https://archive.blender.org/developer/F8802170/49464312.png) And how it looks (1 frame animation render on the right) ![49474414.png](https://archive.blender.org/developer/F8802176/49474414.png) Full demo [2020-08-22_04-07-41.mp4](https://archive.blender.org/developer/F8802165/2020-08-22_04-07-41.mp4) File [double post processing.blend](https://archive.blender.org/developer/F8802179/double_post_processing.blend)

Added subscriber: @Vyach

Added subscriber: @mano-wii

Changed status from 'Needs Triage' to: 'Confirmed'

I can confirm.
It seems that rendering animation doubles color management processing.

I can confirm. It seems that rendering animation doubles color management processing.

Added subscriber: @EAW

To me, this looks like this is the combination of this intentional change in 2.82: 7959dcd4f6 and this change in 2.83+: 190fd795a9 that causes the issue reported in #77909 (2.83lts Regression: Viewport render image ignores colormanagement, and appears to be hardcoded to use sRGB.)

To me, this looks like this is the combination of this intentional change in 2.82: 7959dcd4f6 and this change in 2.83+: 190fd795a9 that causes the issue reported in #77909 (2.83lts Regression: Viewport render image ignores colormanagement, and appears to be hardcoded to use sRGB.)

Poke. Guys, it is important! It spoils animation direct renders.

poke

When rendering an animation frame that would output to an 8bit video/image format performs the color management twice. Also on disk it is applied twice. This is because it is stored in a render buffer and the render buffer assumes that its internal buffer is always stored in Scene Reference Space.
This was introduced in 2.81 to increase the performance when performing viewport animation. As the cause is obvious the solution has to make sure to support all the different use cases there are.

BPY offscreen rendering to Scene reference space. (py_offscreen_draw_view3d calls ED_view3d_draw_offscreen with do_color_management=false).
VSE offscreen rendering to sRGB space
Viewport animation rendering to sRGB space (when saving to 8bit file format)
Viewport animation rendering to linear space (when saving to high bitdepth)
Viewport image rendering to linear space.

P1951 (source graphviz)

Basically looking at the graph we should not perform the in screen_opengl_render_doit as it would render incorrectly to any 8bit file and then also draws it incorrectly in the image editor.

When rendering an animation frame that would output to an 8bit video/image format performs the color management twice. Also on disk it is applied twice. This is because it is stored in a render buffer and the render buffer assumes that its internal buffer is always stored in Scene Reference Space. This was introduced in 2.81 to increase the performance when performing viewport animation. As the cause is obvious the solution has to make sure to support all the different use cases there are. * BPY offscreen rendering to Scene reference space. (`py_offscreen_draw_view3d` calls `ED_view3d_draw_offscreen` with `do_color_management=false`). * VSE offscreen rendering to sRGB space * Viewport animation rendering to sRGB space (when saving to 8bit file format) * Viewport animation rendering to linear space (when saving to high bitdepth) * Viewport image rendering to linear space. [P1951](https://archive.blender.org/developer/P1951.txt) (source graphviz) ![graphviz.png](https://archive.blender.org/developer/F9750589/graphviz.png) Basically looking at the graph we should not perform the in `screen_opengl_render_doit` as it would render incorrectly to any 8bit file and then also draws it incorrectly in the image editor.

diff --git a/source/blender/editors/render/render_opengl.c b/source/blender/editors/render/render_opengl.c
index 5ae952738c9..ba2e23969c6 100644
--- a/source/blender/editors/render/render_opengl.c
+++ b/source/blender/editors/render/render_opengl.c
@@ -367,9 +367,6 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R
     char err_out[256] = "unknown";
     ImBuf *ibuf_view;
     const int alpha_mode = (draw_sky) ? R_ADDSKY : R_ALPHAPREMUL;
-    eImBufFlags imbuf_flags = oglrender->color_depth <= R_IMF_CHAN_DEPTH_8 ? IB_rect :
-                                                                             IB_rectfloat;
-
     if (view_context) {
       ibuf_view = ED_view3d_draw_offscreen_imbuf(depsgraph,
                                                  scene,
@@ -378,7 +375,7 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R
                                                  region,
                                                  sizex,
                                                  sizey,
-                                                 imbuf_flags,
+                                                 IB_rectfloat,
                                                  alpha_mode,
                                                  viewname,
                                                  oglrender->ofs,
@@ -397,7 +394,7 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R
                                                         scene->camera,
                                                         oglrender->sizex,
                                                         oglrender->sizey,
-                                                        imbuf_flags,
+                                                        IB_rectfloat,
                                                         V3D_OFSDRAW_SHOW_ANNOTATION,
                                                         alpha_mode,
                                                         viewname,

should fix this, but seems to renders workbench renders incorrect. the workbench renders are already incorrrect in master.

``` diff --git a/source/blender/editors/render/render_opengl.c b/source/blender/editors/render/render_opengl.c index 5ae952738c9..ba2e23969c6 100644 --- a/source/blender/editors/render/render_opengl.c +++ b/source/blender/editors/render/render_opengl.c @@ -367,9 +367,6 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R char err_out[256] = "unknown"; ImBuf *ibuf_view; const int alpha_mode = (draw_sky) ? R_ADDSKY : R_ALPHAPREMUL; - eImBufFlags imbuf_flags = oglrender->color_depth <= R_IMF_CHAN_DEPTH_8 ? IB_rect : - IB_rectfloat; - if (view_context) { ibuf_view = ED_view3d_draw_offscreen_imbuf(depsgraph, scene, @@ -378,7 +375,7 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R region, sizex, sizey, - imbuf_flags, + IB_rectfloat, alpha_mode, viewname, oglrender->ofs, @@ -397,7 +394,7 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R scene->camera, oglrender->sizex, oglrender->sizey, - imbuf_flags, + IB_rectfloat, V3D_OFSDRAW_SHOW_ANNOTATION, alpha_mode, viewname, ``` should fix this, but seems to renders workbench renders incorrect. the workbench renders are already incorrrect in master.

This issue was referenced by e954e565e1

This issue was referenced by e954e565e1a83e2018278a4be73f5c7ecd22ec45

This issue was referenced by 837b5743ce

This issue was referenced by 837b5743ced83c5dfe724a8285eee504f623dbfb

This issue was referenced by 33145dd187

This issue was referenced by 33145dd187e30916f4ebae81ca0540b9c325b480

Changed status from 'Confirmed' to: 'Resolved'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Double post processing frames with color management, when animation rendered #79999