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

New Issue

Leroy · 2020-06-16T11:20:40+02:00

Leroy commented

2020-06-16 11:20:40 +02:00

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

**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.82a.png](https://archive.blender.org/developer/F8624550/2.82a.png) 2.83: ![2.83.png](https://archive.blender.org/developer/F8624552/2.83.png) [test.blend](https://archive.blender.org/developer/F8624549/test.blend)

Leroy commented

2020-06-16 11:20:40 +02:00

Added subscriber: @Leroy-Xie

blender-admin commented

2020-06-16 11:20:40 +02:00

#102888 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#85397 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#80784 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#80601 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#75280 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#79140 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#79582 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#78914 was marked as duplicate of this issue

blender-admin commented

2020-06-16 11:20:40 +02:00

#78280 was marked as duplicate of this issue

Riccardo Giovanetti commented

2020-06-16 12:12:14 +02:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2020-06-16 12:12:14 +02:00

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.

Leroy commented

2020-06-16 12:27:58 +02:00

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

@Harvester Both in default Filmic, Only happened in Viewport Render, normal render(F12) works fine. ![11.png](https://archive.blender.org/developer/F8624732/11.png)

Riccardo Giovanetti commented

2020-06-16 15:09:39 +02:00

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.

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: ![T77909_filmic.jpg](https://archive.blender.org/developer/F8624950/T77909_filmic.jpg) With Standard (ex. sRGB) CM: ![T77909_sRGB.jpg](https://archive.blender.org/developer/F8624953/T77909_sRGB.jpg) I don't know what's happening with your installation of Blender, that's meat for the developers.

Leroy commented

2020-06-16 15:34:56 +02:00

@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

@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](https://archive.blender.org/developer/F8624989/00.mp4)

Riccardo Giovanetti commented

2020-06-16 16:05:31 +02:00

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.

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.

Evan Wilson commented

2020-06-16 19:50:17 +02:00

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

Evan Wilson changed title from ~~Viewport render image problem in 2.83lts~~ to 2.83lts Regression: Viewport render image ignores colormanagement, and appears to be hardcoded to use sRGB.

2020-06-16 22:42:39 +02:00

Evan Wilson commented

2020-06-16 22:49:10 +02:00

Added subscriber: @EAW

Evan Wilson commented

2020-06-16 22:49:10 +02:00

2.82 render

2.82 viewport render image

2.83 render

2.83 viewport render image

2.82 render ![2.82_Render.png](https://archive.blender.org/developer/F8626495/2.82_Render.png) 2.82 viewport render image ![2.82_Viewport_Render_Image.png](https://archive.blender.org/developer/F8626498/2.82_Viewport_Render_Image.png) 2.83 render ![2.83_Render.png](https://archive.blender.org/developer/F8626500/2.83_Render.png) 2.83 viewport render image ![2.83_Viewport_Render_Image.png](https://archive.blender.org/developer/F8626502/2.83_Viewport_Render_Image.png)

Daniel Calderón commented

2020-06-19 21:00:23 +02:00

Added subscriber: @xdanic

Daniel Calderón commented

2020-06-19 21:00:23 +02:00

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.

Evan Wilson commented

2020-06-19 22:42:35 +02:00

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

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](https://archive.blender.org/developer/F8632524/2.83_0001-0025.mp4) Viewport Render Animation jpg ![2.83_0001.jpg](https://archive.blender.org/developer/F8632525/2.83_0001.jpg) Viewport Render Animation png ![2.83_0001.png](https://archive.blender.org/developer/F8632527/2.83_0001.png) Viewport Render Animation exr 32bit ![2.83_0001.exr](https://archive.blender.org/developer/F8632537/2.83_0001.exr) Viewport Render Image png ![2.83_0001_VRI.png](https://archive.blender.org/developer/F8632531/2.83_0001_VRI.png) Viewport Render Image exr 32bit ![2.83_0001_VRI.exr](https://archive.blender.org/developer/F8632534/2.83_0001_VRI.exr)

Evan Wilson commented

2020-06-19 22:53:44 +02:00

Added subscriber: @Jeroen-Bakker

Evan Wilson commented

2020-06-19 22:53:44 +02:00

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

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

Lsscpp commented

2020-06-20 01:51:33 +02:00

Added subscriber: @lsscpp

Lsscpp commented

2020-06-20 01:51:33 +02:00

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

Evan Wilson commented

2020-06-20 02:23:45 +02:00

Added subscriber: @fclem

Evan Wilson commented

2020-06-20 02:23:45 +02:00

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

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

Clément Foucault self-assigned this 2020-06-20 14:39:29 +02:00

Clément Foucault commented

2020-06-20 14:39:29 +02:00

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.

Daniel Calderón commented

2020-06-21 16:41:54 +02:00

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.

Evan Wilson commented

2020-06-21 20:14:08 +02:00

@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.

@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.

pistol ioan commented

2020-06-23 01:34:43 +02:00

Added subscriber: @istoltoto

pistol ioan commented

2020-06-23 01:34:43 +02:00

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

**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 ![new_viewport_render.jpg](https://archive.blender.org/developer/F8637737/new_viewport_render.jpg) [render_viewport_alternative.py](https://archive.blender.org/developer/F8637734/render_viewport_alternative.py)

Alaska commented

2020-06-26 12:38:23 +02:00

Added subscriber: @SpaceHamster

Lsscpp commented

2020-06-26 18:04:28 +02:00

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?

> 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?

Gints Zilbalodis commented

2020-06-26 19:42:09 +02:00

Added subscriber: @gintszilbalodis

Evan Wilson commented

2020-07-04 22:13:46 +02:00

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.

> 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.

Evan Wilson commented

2020-07-14 12:30:05 +02:00

Added subscriber: @zekizzan

Jon Henry M. Faltis 9077149 commented

2020-07-27 00:02:36 +02:00

Added subscriber: @geocentric_wage

Evan Wilson commented

2020-08-07 03:50:58 +02:00

Added subscriber: @Nasko

Clément Foucault commented

2020-08-12 19:10:59 +02:00

Added subscribers: @oztrkburak, @iss

Clément Foucault commented

2020-08-12 19:11:11 +02:00

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

Leroy commented

2020-08-18 02:54:45 +02:00

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

Antti Teittinen commented

2020-08-18 07:23:06 +02:00

Removed subscriber: @funksy

Dalai Felinto commented

2020-08-19 12:36:47 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2020-08-19 12:36:47 +02:00

@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.

chay hawes commented

2020-08-19 12:41:41 +02:00

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.

> 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.

Antonio Ahrens commented

2020-08-19 12:42:57 +02:00

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

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

Antonio Ahrens commented

2020-08-19 12:44:59 +02:00

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.

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.

Leroy commented

2020-08-20 02:49:28 +02:00

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.

Roman commented

2020-09-06 09:22:56 +02:00

Added subscriber: @rwman

Richard Antalik commented

2020-09-14 18:06:02 +02:00

Added subscriber: @YAFU

Evan Wilson commented

2020-09-14 21:24:42 +02:00

Added subscriber: @vasiln

Antonio Ahrens commented

2020-10-10 05:33:39 +02:00

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?

davinci commented

2020-10-20 14:33:49 +02:00

Added subscriber: @davinci321

davinci commented

2020-10-20 14:33:49 +02:00

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

Daniel Calderón commented

2020-10-20 15:34:58 +02:00

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

davinci commented

2020-10-20 16:26:24 +02:00

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! 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!

Richard Antalik commented

2020-10-21 05:06:34 +02:00

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.

> 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.

Leroy commented

2020-10-22 14:10:32 +02:00

Will this be fixed in Blender 2.91 Release? thanks

Philipp Oeser commented

2020-10-22 14:43:20 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-10-22 14:43:20 +02:00

@fclem: can you check this for 2.91?

davinci commented

2020-11-06 18:26:53 +01:00

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!

Leroy commented

2020-11-07 13:32:25 +01:00

So higher priority, please : )

Nicolas Macilvoy commented

2020-12-13 10:27:37 +01:00

Added subscriber: @Macilvoy

Andy Cuccaro commented

2020-12-20 23:55:11 +01:00

Added subscriber: @AndyCuccaro

Ramil Roosileht commented

2021-01-25 23:31:12 +01:00

Added subscriber: @Limarest

Ramil Roosileht commented

2021-01-25 23:31:12 +01:00

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

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

Jeroen Bakker commented

2021-01-26 12:24:03 +01:00

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.

❤️ 1

Evan Wilson commented

2021-01-26 13:51:01 +01:00

@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.

@Jeroen-Bakker Perhaps adding: ```uniform bool overlay; 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.

Jeroen Bakker commented

2021-01-26 13:56:13 +01:00

@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.

Clément Foucault removed their assignment 2021-02-01 13:19:19 +01:00

Jeroen Bakker self-assigned this 2021-02-01 13:28:59 +01:00

Michał commented

2021-02-02 15:58:42 +01:00

Added subscriber: @MichalDresner