2.83lts Regression: Viewport render image ignores colormanagement, and appears to be hardcoded to use sRGB. #77909

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87

Blender Version
Bisect points to 190fd795a9
Broken: version: 2.83.0, branch: master, commit date: 2020-06-03 14:38, hash: 211b6c29f7
Worked: 2.82a

Short description of error
Viewport Render Image ignores color management. The image produced is clamped to 1.0 according to the color sampler. It appears to be hard coded to sRGB.

Exact steps for others to reproduce the error
Create a Scene that has scene linear color values above 1.0. Render with Filmic. Then do viewport render image and see how it produces an image with blown out highlights.

2.82a:

2.83:

test.blend

Added subscriber: @Leroy-Xie

#102888 was marked as duplicate of this issue

#85397 was marked as duplicate of this issue

#80784 was marked as duplicate of this issue

#80601 was marked as duplicate of this issue

#75280 was marked as duplicate of this issue

#79140 was marked as duplicate of this issue

#79582 was marked as duplicate of this issue

#78914 was marked as duplicate of this issue

#78280 was marked as duplicate of this issue

Added subscriber: @Harvester

Please check that Filmic is set correctly in the Color Management section of the Render Properties. To me they appear to work fine both in Eevee and Cycles, both in 2.82a and 2.83.0. I can get your second image's result only if I set the Color Management to sRGB. Hope this helps.

@Harvester Both in default Filmic, Only happened in Viewport Render, normal render(F12) works fine.

I did a clean install (portable) of version 2.83.0 stable, vanilla, no external add-ons (just in case they might interfere), and I confirm that here the issue raises in the 3D Viewport with Standard (formerly, sRGB) setup for Color Management's View Transform, as per screenshots below:

With FILMIC CM:

With Standard (ex. sRGB) CM:

I don't know what's happening with your installation of Blender, that's meat for the developers.

@Harvester Did you test by viewport render, for me, normal render good, just in viewport render. I am in default setting, have tested in two computer. btw, 2.82a ok.
00.mp4

Yes @Leroy-Xie, the last images I published were taken from the 3D Viewport, not a render.

Ah, sorry, I've just noticed that you are using Eevee and rendering the 3D viewport produces in fact that result, like if Filmic is not being used when rendering the viewport. Just presuming.

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

Added subscriber: @EAW

2.82 render

2.82 viewport render image

2.83 render

2.83 viewport render image

Added subscriber: @xdanic

I found something interesting, when rendering video color management fails, but rendering something like exr or png outputs a correctly exposed image. Also, as I expected png is much slower than exr, which renders practically as fast as video.

I hadn't even tried rendering out as a video or as an animation of pngs/exrs, only as single image exrs and pngs.
Trying it just now, Viewport Render Animation as an H264 and VP9 appears to have more glow.
2.83_0001-0025.mp4
Viewport Render Animation jpg

Viewport Render Animation png

Viewport Render Animation exr 32bit

Viewport Render Image png

Viewport Render Image exr 32bit

Added subscriber: @Jeroen-Bakker

None of them match the Viewport Render Image in 2.82a, which matches the color management of F12 renders.

I did ask, and @Jeroen-Bakker did say (paraphrasing, not a direct quote) that it was an intentional change for animators who want faster performance.

I think he might be referring to a change that I believe was done in 2.82a, which has reports about viewport render image and viewport render animation giving different results, where this report is about the change in viewport render image between 2.83 and 2.82a

Added subscriber: @lsscpp

What? Viewport Render Image is already waaay faster than F12 render. It's perfect for previewing animations at decent quality. Having everything clamped kills the usefulness of the feature

Added subscriber: @fclem

Bisecting shows 190fd795a9 to be the responsible commit.
Paging @fclem

I think this is just a matter of bypassing this clamp when rendering. But like I said in the commit this is to avoid incorrect blending of overlays over HDR values. Doing so only when overlays are enabled is also strange behavior.

I noticed 2.82 still had problems when output is set to video file, images seem to render correctly, you can notice it clearly using false color @EAW Not as much of a problem as long as we have image sequences rending correctly at good speed.

@xdanic that is an intentional change in 2.82 for ‘Viewport Render Animation’ that changes color management depending on the output file’s bit depth. See 7959dcd4f6. See the report #77291 as well, which might have been incorrectly merged into another issue.

Added subscriber: @istoltoto

workaround solution

Instead of using Viewport Render Animation, the script will use Viewport Render Image and move to render the next frame automaticly.
The script have no stop button and is not working with Esc either, so you either leave it to finish till the end of timeline, or you shoutdown the Blender.

Credit to: Jefferson Rausseo

render_viewport_alternative.py

Added subscriber: @SpaceHamster

depending on the output file’s bit depth. See 7959dcd4f6.

Changing output from 8 bit to a 16 or 32 bit format doesn't change the output of Viewport Render Image here. Still clamped. Do you have better luck?

Added subscriber: @gintszilbalodis

In #77909#966767, @lsscpp wrote:

depending on the output file’s bit depth. See 7959dcd4f6.

Changing output from 8 bit to a 16 or 32 bit format doesn't change the output of Viewport Render Image here. Still clamped. Do you have better luck?

@lsscpp Just to be clear, the workaround I am referring to (along with the python scripted version of it that @istoltoto posted) is for the Viewport Render Animation change in 2.82, not this issue with Viewport Render Image in 2.83. However, due to the 2.83 bug, Viewport Render Animation saved in an 8bit format now has 2 transforms (and clamping?). This results in saved files being even farther from what you see in the Viewport.

Added subscriber: @zekizzan

Added subscriber: @geocentric_wage

Added subscriber: @Nasko

Added subscribers: @oztrkburak, @iss

Added subscribers: @Chayground, @VincentBlankfield, @Louis, @TarkanV, @funksy

The problem will fixed in 2.90, or delayed until 2.91? it's very important for rendering.

Removed subscriber: @funksy

Added subscriber: @dfelinto

@Leroy-Xie you can still use F12 and get the correct result from EEVEE, no? In that case, although this is an important issue, it is not as critical for rendering.

In #77909#998611, @dfelinto wrote:
@Leroy-Xie you can still use F12 and get the correct result from EEVEE, no? In that case, although this is an important issue, it is not as critical for rendering.

The difference is with "render viewport animation" I could get usable frames in about 2-4 seconds per frame, with F12 that can sometimes jump to 20-40 seconds per frame.

When the colour was working (back in 2.81) I could render entire projects at a good enough level to use in production using "render viewport" in a matter of minutes, now (using F12) it takes ten times as long.

@dfelinto
I think he`s mainly talking about viewport render animation.
those render significantly faster than eevees normal render animation.

Yea exactly. i sort of came up with a similar method of having a macro using razer synapse to move one frame wait a few MS and then screenshot it to a specific folder then rendering it as a png sequence.
this is a bit of a hassle though since SSR can sometimes leave weird ghosting trails that viewport render animation doesnt and having to change your actual screen resolution for better render performance.

It's helpful if you don't need pass, especially in the rendering animation. it's good choice for Eeevee Engine. another reason, F12 need cameras.

Added subscriber: @rwman

Added subscriber: @YAFU

Added subscriber: @vasiln

Hey! Any updates on wether this problem is going to stay or get resolved since it`s been apparent that the devs intentionally changed the way viewport render image works due to other complications with filmic view transform i guess?

Added subscriber: @davinci321

hello this problem needs be solved make this higher priority. is important issue !

This issue happens when saving EXRs from eevee even from the normal render button, it should be set to high priority!

In #77909#1037876, @xdanic wrote:
This issue happens when saving EXRs from eevee even from the normal render button, it should be set to high priority!

i can confirm that issue is also with regular render button when you set output to exr, i just rendered couple of animation frames with exr output and renders were beyond repair !

@fclem Help!

In #77909#1037876, @xdanic wrote:
This issue happens when saving EXRs from eevee even from the normal render button, it should be set to high priority!

This report is about viewport render. If you have problem with final render please make new report with example file and steps to reproduce.

Will this be fixed in Blender 2.91 Release? thanks

Added subscriber: @lichtwerk

@fclem: can you check this for 2.91?

just want to point out that the patch @Jeroen-Bakker submitted does not completely fix viewport issue as there is still notably reduced quality compared to actual renders especially in objects with sss there is noticeable banding of color. it would be nice if we were able to render from viewport the way it actually looks like and not decimate the quality for no reason. i dont want to wait 2 minutes per frame to render animation if it can be done in 20 seconds per frame in viewport render. alas if it only looked right, but it doesnt. at least give option i dont care about overlay or if overlay is messing things up WE JUST WANT TO RENDER FASTER ANIMATIONS PLEASE!

So higher priority, please : )

Added subscriber: @Macilvoy

Added subscriber: @AndyCuccaro

Added subscriber: @Limarest

Since bug sprint week is upon us, wanted to remind that this is still a severe issue which blocks some concept art and compositing use cases
It's fine if colors are slightly off, but highlights should definitely not be clamped

Color pipelines

Current situation

In blender there are multiple paths where the color management of a render is handled in a different way.
The different paths are:

Viewport Display (What you see in the 3d viewport)
Image Render (F12 render)
Viewport Render Image
Viewport Render Animation (to an 8 bit image)
Viewport Render Animation (to an image with high bitdepth)
Scene Strip & Offscreen render

Viewport Display

The color management is handled in GLSL shaders (gpu_shader_display_transform) Inside that shader the overlay.

Color is transformed to display linear including the look transform.
If the overlay is on - is clamped and the overlay is clamped on top of it.
- is transformed to display encoded.

Image Render

The Color is stored in scene reference space in the render result. Colors aren't clamped and no overlays are composited on top of the result.

Viewport Render Image

Viewport Render Image does not do any color transform during rendering.
The color is clamped and the overlay is composited on top.
NOTE: This results in incorrect renderings as intensive colors are clamped to 1 to make sure that the overlay can be composited on top of it.

Viewport Render Animation (to an 8 bit image)

The color management is handled in GLSL shaders (gpu_shader_image_overlays_merge_frag) Inside that shader the color buffer is clamped,
the overlay is composited on top and the result is transformed to sRGB.
NOTE: When the last frame result is stored as Render Result the image isn't transformed back to Scene ref and is assumed to be in SRS. This leads to the second transform to sRGB.

Viewport Render Animation (to an image with high bitdepth)

PNG16

The color management is handled in GLSL shaders (gpu_shader_display_transform) Inside that shader the overlay.

Color is transformed to display linear including the look transform.
If the overlay is on - is clamped and the overlay is clamped on top of it.
- is transformed to display encoded.

OpenEXR

The color management is handled in GLSL shaders (gpu_shader_image_overlays_merge_frag) Inside that shader the color buffer is clamped,
the overlay is composited on top.

Scene Strip & Offscreen render

Uses OCIO, but somehow the colors are clamped.

NOTE: There is an additional issue with Saving an 8bit images during viewport render animation. In this flow the color management is applied twice. Once during rendering and once when saving. RE_WriteRenderViewsImage.

Current state: Still looking for a short term solution that works in all situations.

# Color pipelines ## Current situation In blender there are multiple paths where the color management of a render is handled in a different way. The different paths are: * Viewport Display (What you see in the 3d viewport) * Image Render (F12 render) * Viewport Render Image * Viewport Render Animation (to an 8 bit image) * Viewport Render Animation (to an image with high bitdepth) * Scene Strip & Offscreen render ### Viewport Display The color management is handled in GLSL shaders (`gpu_shader_display_transform`) Inside that shader the overlay. 1. Color is transformed to display linear including the look transform. 2. If the overlay is on - [x] is clamped and the overlay is clamped on top of it. 3. - [x] is transformed to display encoded. ### Image Render The Color is stored in scene reference space in the render result. Colors aren't clamped and no overlays are composited on top of the result. ### Viewport Render Image Viewport Render Image does not do any color transform during rendering. The color is clamped and the overlay is composited on top. NOTE: This results in incorrect renderings as intensive colors are clamped to 1 to make sure that the overlay can be composited on top of it. ### Viewport Render Animation (to an 8 bit image) The color management is handled in GLSL shaders (`gpu_shader_image_overlays_merge_frag`) Inside that shader the color buffer is clamped, the overlay is composited on top and the result is transformed to sRGB. NOTE: When the last frame result is stored as Render Result the image isn't transformed back to Scene ref and is assumed to be in SRS. This leads to the second transform to sRGB. ### Viewport Render Animation (to an image with high bitdepth) **PNG16** The color management is handled in GLSL shaders (`gpu_shader_display_transform`) Inside that shader the overlay. 1. Color is transformed to display linear including the look transform. 2. If the overlay is on - [x] is clamped and the overlay is clamped on top of it. 3. - [x] is transformed to display encoded. **OpenEXR** The color management is handled in GLSL shaders (`gpu_shader_image_overlays_merge_frag`) Inside that shader the color buffer is clamped, the overlay is composited on top. ### Scene Strip & Offscreen render Uses OCIO, but somehow the colors are clamped. ### NOTE: There is an additional issue with Saving an 8bit images during viewport render animation. In this flow the color management is applied twice. Once during rendering and once when saving. `RE_WriteRenderViewsImage`. Current state: Still looking for a short term solution that works in all situations.

@Jeroen-Bakker Perhaps adding:


if (overlay) {
}```

to `gpu_shader_image_overlays_merge_frag.glsl` so that the color is clamped only if there is an overlay?  Because as of now the clamping occurs with or without an overlay present.

@EAW I already have a patch for that one, but found out that other situations weren't working. So wanted to find out the different situations and why it is failing.

Added subscriber: @MichalDresner

Added subscribers: @zebus3dream, @Blendify

Added subscriber: @Frank-Top

Added subscriber: @1D_Inc

Probably we need two modes

Viewport render animation (fastest)
Viewport render animation (beauty)

Added subscribers: @SergeL, @mano-wii

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations