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?

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

In T64548#678130, @nBurn (nBurn) wrote:

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

Exactly

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

In T64548#678766, @Troy Sobotka (sobotka) 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?

Gif1 - Colorwheel goes 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.

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.