Page MenuHome

Color Wheels not working correctly using using Troy Sobotka version of the OCIO configuration
Closed, ArchivedPublic


System Information
Operating syste[[ URL | name ]][[ URL | name ]]m: osx 10.14.4
Graphics card: Radeon Pro 570

Blender Version
Broken: (example: 2.79, master, 2018-5-23)
Worked: e6acb4fba094

Short description of error
using Troy Sobotka version of the OCIO configuration, which makes Blender work in ARRI Wide Gamut wherever possible, the color wheels go crazy.

Exact steps for others to reproduce the error
replace OCIO with Troy Sobotka's one available at
start blender, set the color space to filmic and add an input>RGB node in compositor.
clicking on color wheel return crazy values
clicking on hsv sliders return crazy values

this is very crucial for vfx compositing. For more info please refer to @Sebastian Koenig (sebastian_k) Working with Blender and the ARRI Alexa post.



Event Timeline

George Vogiatzis (Gvgeo) triaged this task as Needs Information from User priority.

I can't help with the bug(have no idea about color), but this report is a bit confusing.
Either the broken version or the worked on is wrong(the dates/versions do not match). What version has the problem? 2.79 or 2.80?

It really sounds like the OCIO configuration is wrong.
Isn't Troy Sobotka more qualified for this problem?
Does he know this problem?

2.79 is affected. 2.8 seems work quite fine with replaced ocio configs.
As i wrote above this was not working in 2.79b official.
Used to work on e6acb4fba094 and some other previous nightly build downloaded from builder (unfortunately i haven’t saved all the downloads). But i still have e6acb4fba094 and replacing OCIO there makes both ARRI filmic and color wheels work.
If both versions are wrong it’s really strange that there are some versions where this was wrong and working, don’t you think?
What other information you need?

I'm soo... confused.
From what I get:
broken : 2.79b, 2018-3-23 release
worked: 2.79b 2019-1-4 rBe6acb4fba094

If understand it correctly, the problem has been fixed.
Did the latest version stop working again?

Can’t tell if was an intended fix or not.
What i can tell is that was working on e6acb4fba094 and is not working anymore.
I feel like i am writing this for the 3rd time in different words...
What’s missing in my report?

George Vogiatzis (Gvgeo) raised the priority of this task from Needs Information from User to Needs Triage by Developer.May 13 2019, 9:40 PM

Oh, I see now.
It is better to add the version, you found that it is broken again. Helps devs to pinpoint the problem. Even if it is today's build.

nBurn (nBurn) added a subscriber: nBurn (nBurn).EditedMay 14 2019, 12:37 AM

@Ivan Cappiello (icappiello) by "not working anymore" do you mean color wheels and sliders are broken with this OCIO config in the latest 2.79 daily build, d83a72ec104c?

@Ivan Cappiello (icappiello) by "not working anymore" do you mean color wheels and sliders are broken with this OCIO config in the latest 2.79 daily build, d83a72ec104c?


“Go crazy” isn’t a very useful description. Can you provide screenshots or an animated GIF of the issue happening, along with samples of some of the values?

“Go crazy” isn’t a very useful description. Can you provide screenshots or an animated GIF of the issue happening, along with samples of some of the values?

It means that when you try to click and hold, even a little movement makes the pointer jump to the corners of the color wheel and from there it continues jumping around. How do you call this behaviour?

If you do the same in hsv slider you get the same effect with values, meaning that even manually inputing correct values (0.2 for example) the slider returns any kind of result changing all the other untouched values. and switching back to rgb returns values like 1.5 or even 15.
I name this going crazy.

The procedure to reproduce it is pretty easy and straightforward, why do you need a gif?

Gif1 - Colorwheel goes crazy

Gif2 - resulting values and sliders going crazy

The procedure to reproduce it is pretty easy and straightforward, why do you need a gif?

Because not all of us have Blender in front to test exactly what someone is seeing. To this end, thank you so much for taking the time to provide examples.

I believe this is a duplicate of T41287, which doesn’t adequately, despite countless comments, describe the conceptual problem.

The core issue is that all UI must be managed:

  1. Formatted according to the needs of the pixel pusher. The software cannot know what she is trying to do, nor do we want software assuming what she is attempting to do.
  2. Formatted according to the reference space assumptions. The software must honour the reference space primaries and assumptions. Any and all hard coded paths must be replaced with managed code paths.

This particular issue I believe is somewhat a legacy problem due to the way the pickers were originally written.

In this particular case, we have a slider with a range that goes from minimum to maximum, also known as device referred or encoding referred, etc. What are you trying to do? The software can’t know, and as such, the transform needs to be listed below the picker.

  1. If you are painting normals, or depth, or some other arbitrary data range, you likely want the minimum to maximum range, and the wheel, to represent that data range. This too is handled via OCIO.
  2. If you are painting an emission, you likely want the minimum to maximum range representing the emission level in the reference space. For example, with Filmic, that range is 2^-10 * 0.18 to 2^+15 * 0.18, which is 0.00017578125 to around 5898.24.
  3. If you are painting an albedo, you need a normalized linear colour range, representing reflectance ratios for the primary slider range, plus the ability to escape out for unique effects. Etc.

All of the various examples highlight that we can’t hard code the picker to a certain set of assumptions, and that each assumption makes it unworkable for the others.

I tried to fix this once, but the drawing paths are a mess in Blender, and there is no buffer for the UI elements, which prevents it from working properly. What you are seeing is the drawn UI values attempting to be inverted to the reference via the view / display transform, and that can’t work. The values are also whacked because the UI component has certain assumptions baked into it, such as preventing negative values, which happen with wider gamuts transformed to smaller ones.

Proper UI flow should be something like:

  1. Draw the UI as per the chosen transform into a buffer, and assume the range is “as encoded”. These are normally invertible transfer functions that you would select for the transform.
  2. Invert the chosen transform to an in reference state. Examples might be: “depth map”, “normal map”, “sRGB EOTF”, “LogC v3”, “VLog”, “FLog”, “SLog3”, “REC.709 OETF”, etc.
  3. Keep this buffer.
  4. Render the buffer to the display for the appropriate display, and view combination. This might include a dual head system where the display is different from one to the other.
  5. When selecting from the picker, use the xy mouse coordinates to pick from the “in reference” UI buffer, not try and invert the results.

TL;DR: Fixing the UI is quite a task, and given the only capable person is Brecht, and he is grossly overworked on other things, I suspect this will remain broken for a long time to come. Should this be a priority given it is foundational componentry? That’s up to the audience...

Addendum: I tried to explain the situation prior, but it fell on deaf ears, or worse, the “does any other software do this?” response. Sure enough, as of last year, Mari implemented just this sort of approach.

Brecht Van Lommel (brecht) closed this task as Archived.Thu, Jun 6, 5:10 PM
Brecht Van Lommel (brecht) claimed this task.

It appears the new behavior is actually more correct. There was a bug in OCIO where it would not correctly return the default display and view.

To solve the problem, edit your config.ocio like this:

- active_views: [Filmic, Default, RRT, Raw, Log, Arri LogC]
+ active_views: [Default, Filmic, RRT, Raw, Log, Arri LogC]

In 2.8 this is not a problem because color management of color pickers was improved, and now uses the color_picking role rather than the default display.

can confirm that modifying the config as described fixes the issue (using 2.79b official and Troy's config with Brecht's edited line).
Thanks, @Brecht Van Lommel (brecht).

@Troy Sobotka (sobotka) maybe this change should go in your repository too?

@Ivan Cappiello (icappiello) I had ordered the config originally because Blender didn’t have the colour picker role in use, and it went by order for a long time.

I will add it for backwards compatibility.