Color Managed Color Parameter

[revisionfx]

Standard Change Workflow

• [x ] Create proposal as issue (you're doing this now!)
• [x ] Tag this issue with standard change tag

Summary

After we release colorspace suite, we should follow up with color managed color parameter.

Example use cases:

set a red rectangle - user might think in terms of 1,0,0 but the actual given working process colorspace might not be intuitive. pick somewhere on screen to get color somehow set a threshold value slider make your own custom widget (e.g. HLS) map OS supplied color picker (some do that I think when you click on color param)

Problem

likely requires a host call back to return to us chromacites?... perhaps color are always define in linear internally? host might support different display options if they popup a color param editor for such param

[john-paulsmith]

Now that we have colour management support in OFX, this issue becomes feasible to address. My proposed starting point would be to add a new string property OfxParamPropColourspace which stores the colourspace of the colour value stored in the param. The string would follow the same rules as OfxImageClipPropColourspace, i.e. it needs to be valid for the colour management style in use.

Some open questions:

1. Should this property be read/write for both host and plug-in? There are scenarios where the correct colourspace is known to the host (user picks from the image) and others where it is known to the plug-in (loading a preset or performing analysis of an input image).
2. If a plug-in loads a preset which was defined in a different colourspace to the one currently set on the parameter, would it actually be better from a user perspective for the plug-in to transform its colour values into the host's preferred space?

[garyo]

Also how would this property affect the default values the plugin specifies in the param definition? Consider that the param is defined very early. Would this allow a plugin to define a color (ParamTypeRGB) param with an ACEScct color of (100, 10, 1)? That could lead to difficulties on both sides. Currently we just say "Values are always normalised in the range [0 .. 1], with 0 being the nominal black point and 1 being the white point" which is clearly underspecified. Maybe we could allow defaults to be either sRGB (presumably how they're interepreted today??) or a single well-specified wider HDR space, based on a new param definition property?

[revisionfx]

There are two applications:

1. More like UI application (display overlays this color) - what we have for that is fine and could be assumed sRGB or something. Is not critical.
2. Actual image colorspace - sensitive to chromacities and white point after linearization even, related to colorspace in which we process pxiels

Maybe what JP suggests - to simply add a colorspace reference is one way to do it i.e. add an optional property which is a colorspace string, with default what it does right now if optional property not defined. I would not go into supporting color picker param in other than these two cases. Default value: what is default 50% grey? :) - so seems we need maybe 2 properties - boolean: uses rec709/sRGB or native colorspace aside the colourspace itself.

It's not quite clear how one would do a UI for such color picker editor Draw a CIE projection of chromacity triangle of colorspace (instead of a color wheel) and a luminance value slider that reflects the gamma curve??? Or simply display usual color wheel with an additional overlays showing where rec709/sRGB stops?

Doing rudimentary search for wide-gamut color picker or selector I get:

https://docs.krita.org/en/reference_manual/dockers/wide_gamut_color_selector.html https://webkit.org/blog/10042/wide-gamut-color-in-css-with-display-p3/ I see google display a bit like the CSS above an edge line of where sRGB falls...

Pierre