Color Wheels not working correctly using using Troy Sobotka version of the OCIO configuration #64548

New Issue

Ivan Cappiello · 2019-05-13T11:58:02+02:00

Ivan Cappiello commented

2019-05-13 11:58:02 +02:00

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

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

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_k Working with Blender and the ARRI Alexa post.

**System Information** Operating syste[name ]][[ URL | name ](URL)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 - [ ](https://github.com/sobotka/ocio-blender-default/tree/arri-reference) 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_k [Working with Blender and the ARRI Alexa ](http://blendfx.com/working-with-blender-and-the-arri-alexa/) post.

Ivan Cappiello commented

2019-05-13 11:58:02 +02:00

Added subscribers: @sebastian_k, @icappiello

blender-admin commented

2019-05-13 11:58:02 +02:00

#64590 was marked as duplicate of this issue

George Vogiatzis commented

2019-05-13 20:01:05 +02:00

Added subscriber: @Gvgeo-1

George Vogiatzis commented

2019-05-13 20:01:05 +02:00

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?

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?

Ivan Cappiello commented

2019-05-13 20:35:51 +02:00

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 e6acb4fba0 and some other previous nightly build downloaded from builder (unfortunately i haven’t saved all the downloads). But i still have e6acb4fba0 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?

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?

George Vogiatzis commented

2019-05-13 21:10:51 +02:00

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

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

I'm soo... confused. From what I get: broken : 2.79b, 2018-3-23 release worked: 2.79b 2019-1-4 e6acb4fba0 If understand it correctly, the problem has been fixed. Did the latest version stop working again?

Ivan Cappiello commented

2019-05-13 21:15:14 +02:00

Can’t tell if was an intended fix or not.
What i can tell is that was working on e6acb4fba0 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?

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 commented

2019-05-13 21:40:30 +02:00

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.

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 commented

2019-05-14 00:37:02 +02:00

Added subscriber: @nBurn

nBurn commented

2019-05-14 00:37:02 +02:00

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

2019-05-14 06:35:30 +02:00

In #64548#678130, @nBurn wrote:
@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?

Exactly

> In #64548#678130, @nBurn wrote: > @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? Exactly

Brecht Van Lommel commented

2019-05-14 10:52:06 +02:00

Added subscriber: @troy_s

Troy Sobotka commented

2019-05-14 14:57:04 +02:00

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

Ivan Cappiello commented

2019-05-14 17:04:57 +02:00

In #64548#678766, @troy_s wrote:
“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?

> In #64548#678766, @troy_s wrote: > “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?

Ivan Cappiello commented

2019-05-14 17:24:12 +02:00

Gif1 - Colorwheel goes crazy

Gif2 - resulting values and sliders going crazy

Gif1 - Colorwheel goes crazy ![OCIO_colorwheel_spin.gif](https://archive.blender.org/developer/F7036621/OCIO_colorwheel_spin.gif) Gif2 - resulting values and sliders going crazy ![OCIO_colorwheel_values.gif](https://archive.blender.org/developer/F7036622/OCIO_colorwheel_values.gif)

Troy Sobotka commented

2019-05-14 18:17:15 +02:00

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 #41287, which doesn’t adequately, despite countless comments, describe the conceptual problem.

The core issue is that all UI must be managed:

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

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

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.
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.
Keep this buffer.
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.
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.

>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 #41287, 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 commented

2019-06-06 16:40:09 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-06-06 16:40:09 +02:00

Caused by 0152bf2edf.

Caused by 0152bf2edf.

Brecht Van Lommel commented

2019-06-06 17:10:13 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2019-06-06 17:10:13 +02:00

Brecht Van Lommel self-assigned this 2019-06-06 17:10:13 +02:00

Brecht Van Lommel commented

2019-06-06 17:10:13 +02:00

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.

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.

Ivan Cappiello commented

2019-06-14 16:21:18 +02:00

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.

@troy_s maybe this change should go in your repository too?

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. @troy_s maybe this change should go in your repository too?

Troy Sobotka commented

2019-06-14 16:43:05 +02:00

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

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

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Color Wheels not working correctly using using Troy Sobotka version of the OCIO configuration #64548