We should also make sure to not forget about glsl, for now luminance there is based on rgb_to_bw(), see https://developer.blender.org/diffusion/B/browse/master/source/blender/gpu/shaders/gpu_shader_material.glsl;6b107daf23c5b8b6b7b9aebfa7384e103928a8d3$725

Great spot @Kévin Dietrich (kevindietrich), which is exactly why I added you as a subscriber. I also saw one in Freestyle I believe, which is a Python file IIRC.

Working on the byte conversions next.

Hi, looks semi OK to me, I'm not 100% certain if all the operations here are in display or linear space. I think compositor is linear, but image (divers.c) and imagefile (png.c) might not be.

@Antonis Ryakiotakis (psy-fi)

I'm not 100% certain if all the operations here are in display or linear space. I think compositor is linear, but image (divers.c) and imagefile (png.c) might not be.

It doesn't matter. Luminance weights are uniform. That is, if we think about a luminance averaged value being applied to sRGB curved values, the weights are always identical to the values we would apply to display linear or scene linear sRGB values. RGB in sRGB at values 0.7, 0.5, 0.4 are multiplied by exactly the same weights a scene linear set of values of 12.4, 11.3, and 20.1 for example.

Luminance is always the Y position of the primaries for each channel.

Thanks @Sergey Sharybin (sergey) for your eyes. Will make full changes. See notes for further questions that need resolving.

Thanks again folks.

Bar some nitpicks that looks OK to me now, probably some old files may need some kind of version checking though? I don't mind breaking compatibility here because this will be a den of snakes to keep all things compatible. Thoughts?

Regarding legacy files, I believe the worst case weight mangling was approximately 15% for green. I am unsure how to proceed in the color cleanups regarding legacy files, and advice would be appreciated. Versioning strikes me as a potentially problematic implementation?

Also, sorry for spam, but BLI_INLINE doesn't work according to Bishop and testing, without the luminance function being BLI_INLINEd as well.

to be clear, in the interface_*.c files, there is no need to use color-management.

re:

Ultimately even the theme colors should probably be color managed.

This seems to be unnecessarily over-complicating things.
Color management is great for the color pipeline, for screen color, we can use simple approximations.

I'm also against using color management in the GUI. I don't really see a benefit from it, only more work and more complicated code. Looking at the way your patch implements it in the interface_*.c files, seems like it's recalculated on each redraw which is also a big point against it (just had a quick look, didn't investigate deeper).

Seriously folks, it uses a global value. There is el-zippo performance issue here.

Further, with much respect, RGB is a relative color model.

You can't send a value to my display and tell me how it will look. You really can't.

But anyways, I restate:

There is no performance hit. There is no overcomplication.

It is one function now as opposed to five. With a default config, it does exactly what the previous functions did, only accurately.

I don't mean to say that we'll have any performance issues here, but we do have some calculations running on each redraw that are not necessary IMHO. And in general we should try to avoid any unnecessary calculations for frequent redraws. Looking at the simple calculations that are done here, I agree that this is only a really minor point, but still it is one ;)

Besides from that, I did some research and didn't find any software that promotes to have color corrected themes/a color corrected UI. So I still don't see a need to have that and until you can't provide any good points I'll stay with my opinion.

Don't want to sound rude or so, and I'm also not totally against the idea, it's just the question if it's worth it. If we decided to color correct the GUI, that would mean we always had to ensure this is considered.

Where are we at on this?

Endless mailing list thread?

I would love to carry on fixing the color management related issues, but can't exactly move forward until this most basic bit of progress lands.

Bcon1, I will commit this and follow the screams if someone complains.

So, I committed this in two parts, first is OCIO API, then there's a separate commit that plugs this in to blender. Let's hope we get no "my render looks slightly wrong" complaints now.