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

Open
opened 2020-06-16 11:20:40 +02:00 by Leroy · 79 comments

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

2.83:
2.83.png

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)
Author

Added subscriber: @Leroy-Xie

Added subscriber: @Leroy-Xie

#102888 was marked as duplicate of this issue

#102888 was marked as duplicate of this issue

#85397 was marked as duplicate of this issue

#85397 was marked as duplicate of this issue

#80784 was marked as duplicate of this issue

#80784 was marked as duplicate of this issue

#80601 was marked as duplicate of this issue

#80601 was marked as duplicate of this issue

#75280 was marked as duplicate of this issue

#75280 was marked as duplicate of this issue

#79140 was marked as duplicate of this issue

#79140 was marked as duplicate of this issue

#79582 was marked as duplicate of this issue

#79582 was marked as duplicate of this issue

#78914 was marked as duplicate of this issue

#78914 was marked as duplicate of this issue

#78280 was marked as duplicate of this issue

#78280 was marked as duplicate of this issue

Added subscriber: @Harvester

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.

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

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

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

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

With Standard (ex. sRGB) CM:
T77909_sRGB.jpg

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

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

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

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

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
Member

Added subscriber: @EAW

Added subscriber: @EAW
Member

2.82 render
2.82_Render.png
2.82 viewport render image
2.82_Viewport_Render_Image.png
2.83 render
2.83_Render.png
2.83 viewport render image
2.83_Viewport_Render_Image.png

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)

Added subscriber: @xdanic

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

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
2.83_0001.jpg
Viewport Render Animation png
2.83_0001.png
Viewport Render Animation exr 32bit
2.83_0001.exr
Viewport Render Image png
2.83_0001_VRI.png
Viewport Render Image exr 32bit
2.83_0001_VRI.exr

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)
Member

Added subscriber: @Jeroen-Bakker

Added subscriber: @Jeroen-Bakker
Member

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

Added subscriber: @lsscpp

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

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
Member

Added subscriber: @fclem

Added subscriber: @fclem
Member

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

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

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

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

Added subscriber: @istoltoto

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

new_viewport_render.jpg
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)
Member

Added subscriber: @SpaceHamster

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?

> 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

Added subscriber: @gintszilbalodis
Member

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

Added subscriber: @zekizzan

Added subscriber: @zekizzan

Added subscriber: @geocentric_wage

Added subscriber: @geocentric_wage
Member

Added subscriber: @Nasko

Added subscriber: @Nasko

Added subscribers: @oztrkburak, @iss

Added subscribers: @oztrkburak, @iss
Added subscribers: @Chayground, @VincentBlankfield, @Louis, @TarkanV, @funksy
Author

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

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

Removed subscriber: @funksy

Removed subscriber: @funksy

Added subscriber: @dfelinto

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.

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

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

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

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

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.

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: @rwman

Added subscriber: @YAFU

Added subscriber: @YAFU
Member

Added subscriber: @vasiln

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?

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

Added subscriber: @davinci321

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

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!

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

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

Will this be fixed in Blender 2.91 Release? thanks

Will this be fixed in Blender 2.91 Release? thanks
Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Member

@fclem: can you check this for 2.91?

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

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

So higher priority, please : )

So higher priority, please : )

Added subscriber: @Macilvoy

Added subscriber: @Macilvoy

Added subscriber: @AndyCuccaro

Added subscriber: @AndyCuccaro

Added subscriber: @Limarest

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

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
Member

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

  1. Color is transformed to display linear including the look transform.
  2. 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.
Member

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

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

@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

Added subscriber: @MichalDresner

Added subscriber: @MichalDresner
Member

Added subscribers: @zebus3dream, @Blendify

Added subscribers: @zebus3dream, @Blendify
Jeroen Bakker removed their assignment 2021-04-21 08:00:35 +02:00

Added subscriber: @Frank-Top

Added subscriber: @Frank-Top

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

Probably we need two modes

  • Viewport render animation (fastest)
  • Viewport render animation (beauty)
Probably we need two modes - Viewport render animation (fastest) - Viewport render animation (beauty)

Added subscribers: @SergeL, @mano-wii

Added subscribers: @SergeL, @mano-wii
Philipp Oeser removed the
Interest
EEVEE & Viewport
label 2023-02-09 15:14:51 +01:00

Could this be fix with Eevee Next?
Shouldn't it be a task assigned to someone? Please don't forget to fix this bug!

Could this be fix with Eevee Next? Shouldn't it be a task assigned to someone? Please don't forget to fix this bug!
Member

This isn't related to Eevee/Eevee-next, but related to color management. There is a task for supporting HDR content in Blender. That task is more related to this issue.

This isn't related to Eevee/Eevee-next, but related to color management. There is a task for supporting HDR content in Blender. That task is more related to this issue.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser Project (Legacy)
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
28 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#77909
No description provided.