Filmic not working on rendered frame in EEVEE #52046

New Issue

Adam Juhasz · 2017-07-13T15:56:00+02:00

Adam Juhasz commented

2017-07-13 15:56:00 +02:00

System Information
win10 pro dual 1070

Blender Version
Broken: (example: blender-2.80 0837d19-windows64, 2017 07 12 nightly build)
Worked: (optional)

when pressing the render icon under the viewport and getting a rendered image in the image editor a stark difference occurs in whites being clipped (aka filmic not working)

Image attached for clear explanation.

(My first bug report ever!) ?
thanks Dalai for twitter encouragement

**System Information** win10 pro dual 1070 **Blender Version** Broken: (example: blender-2.80 0837d19-windows64, 2017 07 12 nightly build) Worked: (optional)![eevee_fun.png](https://archive.blender.org/developer/F666082/eevee_fun.png) **when pressing the render icon under the viewport and getting a rendered image in the image editor a stark difference occurs in whites being clipped (aka filmic not working)** Image attached for clear explanation. (My first bug report ever!) ? thanks Dalai for twitter encouragement

Adam Juhasz commented

2017-07-13 15:56:00 +02:00

Changed status to: 'Open'

Adam Juhasz commented

2017-07-13 15:56:00 +02:00

Added subscriber: @AdamJuhasz

Dalai Felinto commented

2017-07-13 22:47:38 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2017-07-13 22:47:38 +02:00

Could you please attach the .blend you used to reproduce this issue?

Adam Juhasz commented

2017-07-13 22:58:32 +02:00

eevee_filmic_bug.blend I basically reproduced it (didn't save original, sorry)

[eevee_filmic_bug.blend](https://archive.blender.org/developer/F666379/eevee_filmic_bug.blend) I basically reproduced it (didn't save original, sorry)

Clément Foucault was assigned by Dalai Felinto

2017-07-14 11:50:18 +02:00

Dalai Felinto commented

2017-07-14 11:54:11 +02:00

Added subscriber: @ideasman42

Dalai Felinto commented

2017-07-14 11:54:11 +02:00

Since this is "offscreen" render related, @ideasman42 may want to take a look as well

Clément Foucault was unassigned by Campbell Barton

2017-07-14 13:16:33 +02:00

Campbell Barton self-assigned this 2017-07-14 13:16:33 +02:00

Campbell Barton commented

2017-07-14 13:16:33 +02:00

Added subscriber: @fclem

Clément Foucault commented

2017-07-14 15:56:34 +02:00

The thing is that this offscreen render is using byte buffers. And it output transformed (tonemapped) color to the render result that is transformed again with the color management settings.

Ideally we should output an HDR buffer without color correction but this means transforming all colors from object modes to be linear.

The thing is that this offscreen render is using byte buffers. And it output transformed (tonemapped) color to the render result that is transformed again with the color management settings. Ideally we should output an HDR buffer without color correction but this means transforming all colors from object modes to be linear.

Campbell Barton commented

2017-07-14 17:24:21 +02:00

@fclem, noticed this double transform too (though there was an issue with off-screen buffers - fixed 73b1425297 )

Is rendering float images with HDR reliable with OpenGL3.2?
As in, can we add this with only a few changes to the code?

A short term fix could be to flag the render as having color-management applied.

@fclem, noticed this double transform too (though there was an issue with off-screen buffers - fixed 73b1425297 ) Is rendering float images with HDR reliable with OpenGL3.2? As in, can we add this with only a few changes to the code? A short term fix could be to flag the render as having color-management applied.

Clément Foucault commented

2017-07-14 17:54:51 +02:00

@ideasman42 Yes it's reliable to render to HDR format, this is the bread and butter of eevee. Though it's really not easy to change:

Make OffscreenBuffer use a float point format (RGBA16F/32F) depending on active render engine (Eevee only).
Make Eevee not do the render transform if he is doing a render.
(optionnal) color of other engines won't be correct. Make them linear (somehow), maybe by changing the colors in the UBO struct.

@ideasman42 Yes it's reliable to render to HDR format, this is the bread and butter of eevee. Though it's really not easy to change: - Make OffscreenBuffer use a float point format (RGBA16F/32F) depending on active render engine (Eevee only). - Make Eevee not do the render transform if he is doing a render. - (optionnal) color of other engines won't be correct. Make them linear (somehow), maybe by changing the colors in the UBO struct.

Dalai Felinto commented

2017-07-20 12:14:30 +02:00

Added subscriber: @MikePan

Troy Sobotka commented

2017-07-23 20:02:54 +02:00

Added subscriber: @troy_s

Troy Sobotka commented

2017-07-23 20:02:54 +02:00

(optionnal) color of other engines won't be correct. Make them linear (somehow), maybe by changing the colors in the UBO struct.

Note that the issue isn't just transfer function (intensity mapping of scene referred to display referred or vice versa) but also primaries.

Various game engines are flipping or have flipped their reference primaries (IE the colours for each of the red, green, and blue lights) to different coloured lights from BT.709 / sRGB. These include but aren't limited to ACES AP1, REC.2020 and others.

To do a proper conversion:

Identify the transfer function that maps the scene referred values to the display referred and undo it.
Identify the primary lights for source and destination and transform between them.

This can be distilled into a simple OCIO transform, but it requires more information that simply the transfer function.

> # (optionnal) color of other engines won't be correct. Make them linear (somehow), maybe by changing the colors in the UBO struct. Note that the issue isn't just transfer function (intensity mapping of scene referred to display referred or vice versa) but also primaries. Various game engines are flipping or have flipped their reference primaries (IE the colours for each of the red, green, and blue lights) to different coloured lights from BT.709 / sRGB. These include but aren't limited to ACES AP1, REC.2020 and others. To do a proper conversion: - Identify the transfer function that maps the scene referred values to the display referred and undo it. - Identify the primary lights for source and destination and transform between them. This can be distilled into a simple OCIO transform, but it requires more information that simply the transfer function.

Sergey Sharybin commented

2017-08-24 12:20:59 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2017-08-24 12:20:59 +02:00

Quick solution is to disable view transform for OpenGL render (NOT viewport, but the bpy.ops.render.opengl()). This transform is never supposed to be applied on the render result unless you save the file (saving to non-linear format will apply view transform). You can do that by passing NULL as view transform for IMB_colormanagement_setup_glsl_draw_from_space in DRW_transform_to_display(). This will make things to work as it was supposed to in color pipeline in Blender in respect of view transform.

Here's really dirty implementation of the approach:

P521: Dirty patch for #52046

diff --git a/source/blender/draw/intern/draw_manager.c b/source/blender/draw/intern/draw_manager.c
index d5b2944990b..70db4ed4d84 100644
--- a/source/blender/draw/intern/draw_manager.c
+++ b/source/blender/draw/intern/draw_manager.c
@@ -2388,7 +2388,7 @@ void DRW_transform_to_display(GPUTexture *tex)
 	{
 		Scene *scene = DST.draw_ctx.scene;
 		use_ocio = IMB_colormanagement_setup_glsl_draw_from_space(
-		        &scene->view_settings, &scene->display_settings, NULL, dither, false);
+		        G.is_rendering ? NULL : &scene->view_settings, &scene->display_settings, NULL, dither, false);
 	}
 
 	if (!use_ocio) {
diff --git a/source/blender/editors/render/render_opengl.c b/source/blender/editors/render/render_opengl.c
index 47e8a64cb0b..b492f7f2c50 100644
--- a/source/blender/editors/render/render_opengl.c
+++ b/source/blender/editors/render/render_opengl.c
@@ -283,6 +283,7 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R
 	EvaluationContext eval_ctx;
 
 	CTX_data_eval_ctx(C, &eval_ctx);
+	G.is_rendering = 1;
 
 	if (oglrender->is_sequencer) {
 		SpaceSeq *sseq = oglrender->sseq;
@@ -387,6 +388,8 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R
 		RE_render_result_rect_from_ibuf(rr, &scene->r, ibuf_result, oglrender->view_id);
 		IMB_freeImBuf(ibuf_result);
 	}
+
+	G.is_rendering = 0;
 }
 
 static void screen_opengl_render_write(OGLRender *oglrender)

There will be some issue with color being clipped, because we store OpenGL render as byte buffer.

Proper solution would be to skip any color management in OpenGL rendering and store OpenGL render result as float buffer in RenderResult in linear space.

Quick solution is to disable view transform for OpenGL render (NOT viewport, but the `bpy.ops.render.opengl()`). This transform is never supposed to be applied on the render result unless you save the file (saving to non-linear format will apply view transform). You can do that by passing NULL as view transform for `IMB_colormanagement_setup_glsl_draw_from_space` in `DRW_transform_to_display()`. This will make things to work as it was supposed to in color pipeline in Blender in respect of view transform. Here's really dirty implementation of the approach: [P521: Dirty patch for #52046](https://archive.blender.org/developer/P521.txt) ``` diff --git a/source/blender/draw/intern/draw_manager.c b/source/blender/draw/intern/draw_manager.c index d5b2944990b..70db4ed4d84 100644 --- a/source/blender/draw/intern/draw_manager.c +++ b/source/blender/draw/intern/draw_manager.c @@ -2388,7 +2388,7 @@ void DRW_transform_to_display(GPUTexture *tex) { Scene *scene = DST.draw_ctx.scene; use_ocio = IMB_colormanagement_setup_glsl_draw_from_space( - &scene->view_settings, &scene->display_settings, NULL, dither, false); + G.is_rendering ? NULL : &scene->view_settings, &scene->display_settings, NULL, dither, false); } if (!use_ocio) { diff --git a/source/blender/editors/render/render_opengl.c b/source/blender/editors/render/render_opengl.c index 47e8a64cb0b..b492f7f2c50 100644 --- a/source/blender/editors/render/render_opengl.c +++ b/source/blender/editors/render/render_opengl.c @@ -283,6 +283,7 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R EvaluationContext eval_ctx; CTX_data_eval_ctx(C, &eval_ctx); + G.is_rendering = 1; if (oglrender->is_sequencer) { SpaceSeq *sseq = oglrender->sseq; @@ -387,6 +388,8 @@ static void screen_opengl_render_doit(const bContext *C, OGLRender *oglrender, R RE_render_result_rect_from_ibuf(rr, &scene->r, ibuf_result, oglrender->view_id); IMB_freeImBuf(ibuf_result); } + + G.is_rendering = 0; } static void screen_opengl_render_write(OGLRender *oglrender) ``` There will be some issue with color being clipped, because we store OpenGL render as byte buffer. Proper solution would be to skip any color management in OpenGL rendering and store OpenGL render result as float buffer in RenderResult in linear space.

Campbell Barton commented

2017-09-07 19:50:42 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2017-09-07 19:50:42 +02:00

blender-admin commented

2017-09-07 19:52:31 +02:00

This issue was referenced by df58d6bf76

This issue was referenced by df58d6bf76e6551e26fe64480b842f0e18b75e4b

Roberto Roch Diago commented

2020-06-01 18:55:00 +02:00

Added subscriber: @RobertoRoch

Roberto Roch Diago commented

2020-06-01 18:55:00 +02:00

Apologies for resurrecting this issue, this is probably just a problem with my blender setup

I tried again with an empty scene and it doesn't seem to happen, but it does if I copy/paste the objects from my scene to a new file

I've uploaded a file in case anyone wants to test (the problem happens for me when using the Viewport Render Image option in the View menu)
012_03_d.blend

Apologies for resurrecting this issue, this is probably just a problem with my blender setup ![exposure_viewport_render.jpg](https://archive.blender.org/developer/F8570191/exposure_viewport_render.jpg) I tried again with an empty scene and it doesn't seem to happen, but it does if I copy/paste the objects from my scene to a new file I've uploaded a file in case anyone wants to test (the problem happens for me when using the Viewport Render Image option in the View menu) [012_03_d.blend](https://archive.blender.org/developer/F8570400/012_03_d.blend)

Emir Sinan Gürlek commented

2020-06-01 19:04:16 +02:00

Added subscriber: @filibis

Dominic commented

2020-10-17 11:13:36 +02:00

Added subscriber: @Winderlook

Dominic commented

2020-10-17 11:13:36 +02:00

Why is the topic closed when the problem still occurs? The newest blender for now - 2.90.1 still makes double view transform when rendering both viewport image and viewport animation, when using eevee with filmic. Terrible bug.

Sergey Sharybin commented

2020-10-19 10:05:27 +02:00

It might be re-introduced issue, might be different codepath.

Please submit new bug report rather that leaving comment in the older one. This ensures nothing is slipped through the crack, and gives clear and isolated case for developers to look into.

It might be re-introduced issue, might be different codepath. Please submit new bug report rather that leaving comment in the older one. This ensures nothing is slipped through the crack, and gives clear and isolated case for developers to look into.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Filmic not working on rendered frame in EEVEE #52046

(optionnal) color of other engines won't be correct. Make them linear (somehow), maybe by changing the colors in the UBO struct.