Description
As a developer building Python tools using OIIO, it would be great to be able to manage and use ColorConfig instances (including the default instance) using the OIIO Python bindings. To that end, there are a couple of extensions to the current color config support that would be very useful.
Support passing ColorConfig instances to Python IBA functions
OIIO exposes the ColorConfig class through the Python bindings, but the color-related ImageBufAlgo functions that take a colorconfig argument only accept a string value. It would be great to be able to pass an actual ColorConfig instance to these functions, so that the host code using OIIO could create and manage color configs itself.
Support managing the default ColorConfig instance using the OIIO API (including from Python)
OIIO partially piggybacks on OCIO's concept of a global config instance by looking up OCIO::GetCurrentConfig() to underpin any ColorConfig that is instantiated with an empty string.
However, when using OIIO in an environment where the OCIO libraries/bindings OIIO uses may not be available at runtime (e.g. due to namespace differences, etc), there is no way to set the global OCIO config in order to change the behavior of future default-constructed ColorConfig instances. The only way to influence them at all is to set the OCIO environment variable, but since OCIO caches the first config created from the environment when you call OCIO::GetCurrentConfig(), the OCIO config used for default-constructed ColorConfig cannot be swapped out after its first use.
I think these pitfalls could be avoided if OIIO added a basic API for getting/setting the default ColorConfig instance (maybe via static getter/setter methods?).
I would say the first request would definitely be more important/impactful than the second, but both would be much appreciated.