OpenColorIO improvements, especially for 2.2

[lgritz]

• When OIIO builds against OCIO >= 2.2, in the event that there is no config supplied (e.g., specified by env $OCIO), use he new built-in "cg" config to supply a basic set of color spaces and transformations. Yay for OCIO 2.2 and its built-in configs!

• New OIIO-understood aliases (regardless of whether they were in the config or not): "scene_linear", "srgb", "lin_srgb", and "ACEScg". It will do its best to know which, if any, supported color spaces are equivalent to these, even if arbitrarily named. For OCIO >= 2.2, some trickery is employed to use the new features that can convert to built-in config color spaces, transforming several colors in this manner and seeing if it gets what would be expected for various canonical color spaces.

• oiiotool --help now a much abbreviated set of color information (just the OCIO version, and the config, and a hint about how to get more info).

• A new command oiiotool --colorconfiginfo prints the FULL inventory of color management information, which now has been expanded to reveal the aliases of each color space, print the roles, and generally spruce up the output to be much more readable (though longer) for large configs.

• New methods for our ColorConfig class:

  • resolve(name) turns the name, which could be a color space, an alias, a role, or an OIIO-understood universal name (like "sRGB") into a canonical color space name.
  • equivalent(name1,name2) returns whether or not the two names refer, ultimately, to equivalent color spaces (to the best of its ability to figure out).

• Some minor changes (including additional const qualifiers) on the ColorConfig class.

• Make testsuite tests use the built-in OCIO config if OCIO 2.2+ is found.

• Build sonar against ocio2.2 so we are primarily testing the new code paths.

• For OCIO >= 2.2, because we can count on the built-in configs, conditionally compile a bunch of hard-coded color transforms. These will eventually disappear completely, someday, when OCIO 2.2 is the minimum supported version.

I think the behavior should all be largely unchanged when running OIIO in a facility that has a proper OCIO config pointed to by the $OCIO env variable and using color space names contained therein. So studio users will (I hope) see no changes. For users that have no OCIO config, or that are writing software that they want to work reasonably well for common cases no matter what config they encounter at runtime, this should give more helpful and consistent behavior when OCIO 2.2+ is used (which I now strongly recommend for anybody not constrained to 2.1 for compatibility reasons.

But because of the risk and the possible behavioral changes, this is all currently envisioned as OIIO 2.5 features, and I am not planning to backport it to the 2.4 release branch. Additionally, a lot has changed and I expect some additional tweaking and identification of edge cases I may have missed.

[lgritz]

I should note that this is a big change that can cause behavior changes, especially when people switch to OCIO 2.2. As any unwanted or confusing changes get complaints, we can make amendments to the logic. I suspect this will be modified a few times before summer when it is incorporated into a supported release.

Here's how I think the cases break down:

No OCIO support at build time should not change any behavior. It will still understand how to linear<->sRGB, and not much else.

A fully color managed environment -- i.e. $OCIO points to a config and any color conversion functions reference color space names that are in the config -- should not change any behavior. I expect this is the standard setup for large studios.

Building against OCIO <= 2.1, but no OCIO config found at runtime -- this has traditionally been the usual case for people who get OIIO from package managers that provide the OCIO dependency, but that aren't themselves using a color managed workflow. Behavior shouldn't change, but maybe it did unintentionally and I will fix it if there are complaints.

Building against OCIO 2.2, but no OCIO config found at runtime (this should be increasingly common and the new case going forward of package manager, but no color managed workflow) will have greatly expanded capabilities because it will know about all the color management. There may be behavior changes, and I'm amenable to modifying them, but I'm not sure how to avoid any possible changes, because... Caveat emptor: the built-in OCIO 2.2 configs assume a scene_linear default working space with ACEScg color primaries. This is different from the no-config behavior of OCIO <= 2.1 or no-OCIO, because those previously would have interpreted a scene_linear->sRGB (say) as only a change in transfer function and not in color primaries. People who previously had used "linear" or "scene_linear" to describe color spaces of unknown (but presumed linear) files might want to switch to "lin_srgb" to be more specific that they are presuming the file has sRGB primaries.

[lgritz]

Does anybody have concerns about this direction? I expect some refinement rounds before it's in a supported release series.

[lgritz]

OK, merging. Let me know if any problems crop up.