That is a good one. In the gpu/draw module it is also confusing when we mean sRGB (themes) and when it is linear, but with byte encoding. What happens to be implemented as srgb.

I prefer the term SceneLinearByteEncoded. A bit long, but gives clarity.

Would this then also be the time to link this to actual ocio config. I do see some challenges there and would suggest to do it as a separate project after this one is completed due to the tight relation with srgb buffers and different goals (code deconfussion vs more flexible color pipeline).

ByteEncoded sounds good to me.

I'm not sure what linking to the OCIO config means exactly, but I think just naming the colors after the roles they correspond to in the OCIO config is most important.

I don't think this kind of automatic conversion in a constructor is good.

These conversions can be lossy. For example you would not want a function that has a temporary variable with a different alpha mode than the data it is operating on, because you will lose data.

What I think is helpful is communicating intent and type safety. I'd rather have specific functions that associate/unassociate alpha, decode/encode byte colors, etc.

In this design ColorGeometry always has exactly four floats, right?
I think having the 4f suffix is useful, just to better understand what the type is when looking at the name.

Although I tried to do no conversion in constructor at all, it wasn't working for me. The compiler wasn't smart enough to select the correct template function. Hence it is commented out.

When using specific conversion methods introduces more bugs as you really need to specify the correct constructor. When this isn't done the compiler will select float* or uint8_t* constructor what isn't expected by the developer. See SrgbStraightToSceneLinearPremultiplied for example where every step needs to be specified.

We could simplify this for common transformations, but I think the current setup is too error-prone.

Another solution would be to make the color space + storage as a single class with concrete methods eg Srgb4b/SceneLinear4f as subclasses from abstract classes Color4b and Color4f

I think it's fine to do no color space conversion in constructors and only use standalone functions with descriptive names instead. That should make things more explicit indeed.

I can see the issue with the float/uint8_t * constructor. The issue here is not really the constructor though but the implicit conversion to a pointer. This was causing issues for float3 as well sometimes. The best solution might be to just remove operator float *() and similar conversion operators. Instead people could use &color.r or something like color.ptr(). It's not pretty but at least it does not have these issues.

new line

Add newline.

Add newline.

sRGB

I am a bit between two solutions here. Theme colors are in sRGB. when removing sRGB and not changing the current logic users would do the conversion the old way that is error prone.

 char theme_color[4];
 float linear_color[4];
 srgb_to_linearrgb_v4(linear_color, srgb_color)
ColorSceneLinear4f<eAlpha::Straight> scene_linear(linear_color)

A future proof solution would be to use OCIO for the conversion between known color spaces and roles.

I think you're right to remove the confusion from start and only add it when we have connected it to color management.

Both premultiplied and straight is used in blender (compositor and selected operations).
My proposal would be to remove ColorSceneReference4f and ColorSceneReference4b and use the actual classes

using ColorGeometry4f = ColorSceneLinear4f<eAlpha::Premultiplied>;
using ColorGeometry4b = ColorSceneLinearByteEncoded4b<eAlpha::Premultiplied>;

I think it's fine to have a color space for theme colors. And a case I forgot is the usage of theme colors in the viewport background, which needs a conversion to scene linear.

Maybe we can rename ColorSrgb to ColorTheme or ColorUI?

Fine with me too.

I change it to encode/decode.