Page MenuHome

Color management is broken in the Sequencer
Open, NormalPublic

Description

System Information
Operating system: Linux-5.0.21-1-MANJARO-x86_64-with-arch-Manjaro-Linux 64 Bits
Graphics card: Mesa DRI Intel(R) Sandybridge Mobile Intel Open Source Technology Center 3.3 (Core Profile) Mesa 19.1.1

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-10 15:05, hash: rBbb7b741d2f1c
Worked: earlier build of 2.80 (hash: d62a749fcf48) and 2.79

Short description of error
Weird things happens when changing the color management settings in the VSE:

  • wrong color display
  • make sound

Exact steps for others to reproduce the error
With a movie strip displayed on the sequencer, changing the sequencer_colorspace_settings property in the Color Management changes the look of the image even when there is no color correction modifier on the strip. Example: using filmic log instead or sRGB will change the look which it should not.
Also, changing this setting does not apply the change directly, the VSE has to be refreshed.

Another issue with the color management is the change of exposure and gamma setting is way slower than it was on earlier build and it also makes the sound of the current strip/frame do some noise.

Details

Type
Bug

Event Timeline

With a movie strip displayed on the sequencer, changing the sequencer_colorspace_settings property in the Color Management changes the look of the image even when there is no color correction modifier on the strip. Example: using filmic log instead or sRGB will change the look which it should not.

see T65271: Using Filmic view transform causes VSE to be lower contrast than it should be

Also, changing this setting does not apply the change directly, the VSE has to be refreshed.
Another issue with the color management is the change of exposure and gamma setting is way slower than it was on earlier build and it also makes the sound of the current strip/frame do some noise.

This would be bug though.

Brecht Van Lommel (brecht) triaged this task as Needs Information from User priority.

We require a .blend file and exact steps to reproduce the problem.

This is a different topic. I'm not talking about display result with Filmic that dipslay sRGB files less contrasted which is normal.

Let's say you uses the VSE with "Standard" view transform (old sRGB). If you put a movie in the VSE with Blender 2.79, set the "Sequencer" color management to anything without having any color modifier on the strip, the result looks the same. It makes the sequencer able to work in any working colorspace for grading. Do the same with the current 2.80 version and switch for instance the "Sequencer" color management between sRGB and Filmic Log and the result will look different. This is also problematic when using another ocio config file (like the one of ACES with ACEScc working space).

Here is two .blend files that have a different sequencer color management. Open it and compare the result in 2.80, it does not look identical. Open the same files with 2.79 and the result is the same.
I think the correct behavior was the one of 2.79.

Brecht Van Lommel (brecht) raised the priority of this task from Needs Information from User to Needs Triage by Developer.Jul 11 2019, 4:17 PM
Richard Antalik (ISS) triaged this task as Normal priority.Jul 15 2019, 8:34 PM

d62a749fcf48 is not that old, though I am not aware of any changes here.

I will investigate

@Vincent Girès (VincentG) your GPU is not officially supported from Blender, it is too old to match minimum Blender requirement

https://www.blender.org/download/requirements/

@Vincent Girès (VincentG) your GPU is not officially supported from Blender, it is too old to match minimum Blender requirement
https://www.blender.org/download/requirements/

Indeed, I was reporting the bug on my laptop. Here is my working machine where it does the same for both issues:
Operating system: Linux-3.10.0-327.el7.x86_64-x86_64-with-centos-7.2.1511-Core 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.77

d62a749fcf48 is not that old, though I am not aware of any changes here.
I will investigate

Sorry for the mess of my report, I sent more or less two different issues within the same task.

  • d62a749fcf48 do not have the issue of the exposure/gamma that makes some noise with a strip that have sound and changing those setting in this build is very fast to compute. Latest build is slower, this is significant on low-end machine.
  • About the working space that give different result even on strips without color correction, d62a749fcf48 behave the same than the latest build and I didn't succeed to build older commit (from the beginning of 2.80) to try to see if it was already there or not. But the 2.79 with the files I've uploaded is not displaying the same result than 2.80. Maybe the ocio.config file has changed? or maybe the result is correct now and was not before?

The exposure/gamma setting make noise only when audio scrubbing is checked.

By curiosity, I tried to use the config.ocio file from 2.80 in 2.79 and there is no issue while using the config file of 2.79 in 2.80 still have not identical render with the two files I've uploaded. It's then probably not related to the new ocio file and something has been broken in 2.80.
Hope it helps.

By curiosity, I tried to use the config.ocio file from 2.80 in 2.79 and there is no issue while using the config file of 2.79 in 2.80 still have not identical render with the two files I've uploaded. It's then probably not related to the new ocio file and something has been broken in 2.80.
Hope it helps.

It does help.
Thanks.