Color discrepancy in highlights between the 3D viewport render and the Offline Render under certain view-transforms #56055

New Issue

Joaquín Kierbel · 2018-07-20T02:52:51+02:00

Joaquín Kierbel commented

2018-07-20 02:52:51 +02:00

System Information
Windows 10 - GTX 770

Blender Version
Broken: 2.79b, f4dc9f9d68 (the current official release at the time of reporting, and tested in several others 2.79 builds with equal results)

Description:
Depending on the behaviour of the selected view-transform, there is a color discrepancy between the live render in the 3D viewport and the offline render from the UV/Image Editor. This is a Color Management bug not related to the already known alpha issues causing discrepancies between this two viewers, I clarify just in case they might be confused.

This difference is only notably visible in "over-exposed" conditions, when CMed values approach and/or reach [1.0,1.0,1.0] in their RGB triplet on scene values that have one channel at near 0.0. For the purpose of making the difference clearly noticeable, this tests have been performed with an extremely bright Sun lamp on pure colors and white, and can be seen under the following view-transforms in Blender's default Color Management settings:

Filmic
False Color
RRT

Note that when using the official Filmic release by Troy Sobotka this issue is not present and both viewers match accordingly on all view-transforms (4th screen-capture example with False Color using official Filmic). Issue is present in Blender's implementation of Filmic (plus that RRT transform it ships with)

After consulting with him about it he suggested the problem was about GPU Allocation variables. Far from my area of knowledge so I'm not in position to confirm this.

It occurs both rendering with GPU and CPU.

This first capture is just a reference of how the scene looks like under normal lighting conditions.

Sun Lamp intensity increase to 200k to make the differences obvious:

Viewport UP - Offline DOWN - Filmic view-transform (Blender's)

Viewport UP - Offline DOWN - RRT view-transform

Viewport UP - Offline DOWN - False Color view-transform (Blender's)

Viewport UP - Offline DOWN - Filmic view-transform (Official Troy's Filmic release)

Exact steps for others to reproduce the error

Open the attached .blend file in Blender (for convenience, Load UI).
Press F12 for an offline render.
Press Shift + Z in the viewport for Render view.

Difference should be apparent as in the screen-captures presented when using either Filmic, False Color, or RRT transforms.

ColorTest_ViewvRender01.blend

This results can be also spotted by using lower Sun intensities and increasing the exposure value (in the Color Management panel), as long as the initial values are high enough to reach the point in which the discrepancy becomes apparent, which are the very highlights, and shows the following behaviour that you can test from the unmodified blend file:

With e. g. Filmic set as view-transform, and Exposure set to "-10", both viewers match. Going through the image with the color picker and looking at the CMed values you can see that as you increase the Exposure and the CMed values in the RGB triplet start approaching [1.0,1.0,1.0] at about -8.5 stops and above, Filmic's desaturation kicks in seemingly properly on the Offline render, but seems to "cap" prior of reaching fully desaturated over-exposed results in the active viewport. Similar effects can be notice at nearby exposure levels on False Color and RRT, not on other view-transforms (that I could notice).

EDIT: Added some clarity and fixed a typo

**System Information** Windows 10 - GTX 770 **Blender Version** Broken: 2.79b, f4dc9f9d68b (the current official release at the time of reporting, and tested in several others 2.79 builds with equal results) **Description:** Depending on the behaviour of the selected view-transform, there is a color discrepancy between the live render in the 3D viewport and the offline render from the UV/Image Editor. This is a Color Management bug **not related to the already known alpha issues causing discrepancies between this two viewers**, I clarify just in case they might be confused. This difference is only notably visible in "over-exposed" conditions, when **CMed values** approach and/or reach [1.0,1.0,1.0] in their RGB triplet on scene values that have one channel at near 0.0. For the purpose of making the difference clearly noticeable, this tests have been performed with an extremely bright Sun lamp on pure colors and white, and can be seen under the following view-transforms in Blender's default Color Management settings: - Filmic - False Color - RRT Note that when using the official Filmic release by Troy Sobotka this issue is **not present** and both viewers match accordingly on all view-transforms (4th screen-capture example with False Color using official Filmic). Issue is present in Blender's implementation of Filmic (plus that RRT transform it ships with) After consulting with him about it he suggested the problem was about **GPU Allocation variables.** Far from my area of knowledge so I'm not in position to confirm this. It occurs both rendering with GPU and CPU. This first capture is just a reference of how the scene looks like under normal lighting conditions. ![01_Sun_4_sRGB_REF.jpg](https://archive.blender.org/developer/F3995850/01_Sun_4_sRGB_REF.jpg) Sun Lamp intensity increase to 200k to make the differences obvious: Viewport UP - Offline DOWN - Filmic view-transform (Blender's) ![03_Sun_200k_Filmic.jpg](https://archive.blender.org/developer/F3995691/03_Sun_200k_Filmic.jpg) Viewport UP - Offline DOWN - RRT view-transform ![04_Sun_200k_RRT.jpg](https://archive.blender.org/developer/F3995694/04_Sun_200k_RRT.jpg) Viewport UP - Offline DOWN - False Color view-transform (Blender's) ![06_Sun_200k_FalseColor.jpg](https://archive.blender.org/developer/F3995695/06_Sun_200k_FalseColor.jpg) Viewport UP - Offline DOWN - Filmic view-transform (Official Troy's Filmic release) ![07_Sun_200k_FalseColor_OfficialFilmic.jpg](https://archive.blender.org/developer/F3995693/07_Sun_200k_FalseColor_OfficialFilmic.jpg) **Exact steps for others to reproduce the error** 1. Open the attached .blend file in Blender (for convenience, Load UI). 2. Press F12 for an offline render. 3. Press Shift + Z in the viewport for Render view. Difference should be apparent as in the screen-captures presented when using either Filmic, False Color, or RRT transforms. [ColorTest_ViewvRender01.blend](https://archive.blender.org/developer/F3995696/ColorTest_ViewvRender01.blend) This results can be also spotted by using lower Sun intensities and increasing the exposure value (in the Color Management panel), as long as the initial values are high enough to reach the point in which the discrepancy becomes apparent, which are the very highlights, and shows the following behaviour that you can test from the unmodified blend file: With e. g. Filmic set as view-transform, and Exposure set to "-10", both viewers match. Going through the image with the color picker and looking at the **CMed values** you can see that as you increase the Exposure and the CMed values in the RGB triplet start approaching [1.0,1.0,1.0] at about -8.5 stops and above, Filmic's desaturation kicks in seemingly properly on the Offline render, but seems to "cap" prior of reaching fully desaturated over-exposed results in the active viewport. Similar effects can be notice at nearby exposure levels on False Color and RRT, not on other view-transforms (that I could notice). *EDIT: Added some clarity and fixed a typo*

Joaquín Kierbel commented

2018-07-20 02:52:51 +02:00

Added subscriber: @JoaquinKierbel

Bastien Montagne commented

2018-07-26 15:05:32 +02:00

Added subscribers: @Sergey, @brecht, @mont29

Brecht Van Lommel was assigned by Bastien Montagne

2018-07-26 15:05:32 +02:00

Bastien Montagne commented

2018-07-26 15:05:32 +02:00

@brecht or @Sergey may want to check on that one? Thanks.

Troy Sobotka commented

2018-11-06 19:20:18 +01:00

Added subscribers: @JoniMercado, @troy_s

Troy Sobotka commented

2018-11-06 19:20:19 +01:00

This is an easy fix I believe in the broken GPU allocation.

Line 82 should be changed from:

    allocationvars: [-15, 6]

To:

    allocationvars: [-12.473931188, 12.526068812]

Props to @JoniMercado for the testing, and @JoaquinKierbel for the eyes to spot it.

@brecht easy one line patch here for 2.8.

This is an easy fix I believe in the broken GPU allocation. Line 82 should be changed from: ``` allocationvars: [-15, 6] ``` To: ``` allocationvars: [-12.473931188, 12.526068812] ``` Props to @JoniMercado for the testing, and @JoaquinKierbel for the eyes to spot it. @brecht easy one line patch here for 2.8.

blender-admin commented

2018-11-06 19:35:50 +01:00

This issue was referenced by 81e2515a04

This issue was referenced by 81e2515a0460a6b090e28efab50d95de390043c6

Brecht Van Lommel commented

2018-11-06 19:38:04 +01:00

Thanks, will commit.

Brecht Van Lommel commented

2018-11-06 19:47:47 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2018-11-06 19:47:47 +01:00

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

Color discrepancy in highlights between the 3D viewport render and the Offline Render under certain view-transforms #56055