AcademySoftwareFoundation
Default configs
Following up on recent suggestions by @lgritz and @hodoulp, I'm creating an issue to capture thoughts on the topic of whether the OCIO library should provide one or more default configs. There are already a variety of open source configs available for use with OCIO, but it currently requires action on the part of either a developer or end-user to make use of them. We could try to simplify this.
This raises a number of questions for the community:
- Should there be one or more configs that are somehow included with OCIO itself?
- Should OCIO try to recommend a single config as a default for everyone?
If the community decides it's something to pursue, here are some of the questions to consider:
One or more defaults?
The Configs working group has several new ACES-related configs in progress: the Reference config, the Studio config, and the CG config. There seems to be a sense from many people that the CG config, which attempts to be a simple, minimalist, ACES-based config might make a nice general purpose default. But it does not include camera color spaces, so while it might be a good default for general CG artists, it might not be a good default for compositors, for example. Likewise, should the default include any other viewing transforms in addition to ACES? One approach would be for OCIO to provide a few defaults (with some guidelines about which to use for various user personas) but not weigh-in on a single default for everyone.
Where are the defaults stored?
If the community decides to provide defaults, the next question is how to make them available. One option would be to define a directory location for each platform and have the OCIO installer, when it installs the library, install one or more default configs in that location. Another option would be for the configs to be built into the library itself, so that no external files are required. Obviously having them be built in seems cleaner, but on the other hand, it could be nice to have a standard directory location for putting configs. People may find this useful for adding their own defaults, to be shared among several applications on a workstation, for example. Having them be external files also makes it simpler to handle defaults that require external LUTs.
Backwards compatibility
We will have to discuss whether inclusion in the library itself (either directly or via the installer) is sustainable since the intent is that the CG config will evolve as ACES evolves. Applications typically need to be able to load scenes/projects/etc. that were created in previous releases and so we need to consider whether the CG config (assuming that is chosen as the single default) will always support backwards compatibility. Because OCIO relies heavily on the color space name strings, this could potentially tie the hands of the working group as new versions of ACES are released. If the configs working group decides it will not guarantee backwards compatibility, then we will need to decide whether it will be up to the OCIO library (e.g., CreateDefault(version)) or the client application (e.g., config.serialize(ostream), if the config is built in) to deal with it.
API
The next question is about what the API should look like. OCIO already has a CreateRaw() function which was intended to be used when the config path is unavailable or won't load. It essentially turns off color management for the app while still allowing it to function. This should continue to be the fallback when a config path is set but not working. But we could add a CreateDefault() function, which returns a single default config for apps to use when no config path has been specified. A CreateDefault(identifier) function could handle the case of both multiple versions (for backwards compatibility over time) and multiple defaults (e.g., CG config and Studio config).
Unified notation for default and user-defined configs
Currently, many applications store the path to the config along with scenes/projects/etc. It would be nice if they could continue to simply store a "config string" regardless of whether the config is something installed by the end-user or a default provided by OCIO. One way to facilitate this would be to define a special syntax for the config path string (e.g., a DEFAULT_CONFIG prefix or something like that) which would tell OCIO to interpret it as naming a default rather than a directory path. We would then ensure that the config CreateFromFile(string) and CreateFromEnv() functions works with either.
Delighted to see movement on this front. The CG config is exactly the type of thing I was looking for and seems like an excellent standard for CG artists to use across all their apps. It's very similar to the pared down config I made for myself based on ACES 1.2. The only downside is it's OCIOv2.1, which isn't supported everywhere yet (I'm thinking Houdini and RenderMan specifically). That's not ASF's problem though and will no doubt be addressed in time. Thanks, and keep up the great work!
I agree that this would be nice to have, I can certainly see this being used by software such as oiiotool to provide colour management without relying on external configs being present. Maybe a useful notation to reference such a config could be something similar to Qt resources, ie. a name that starts with a :/.
At first glance I would lean toward storing the configs directly in the compiled library and restricting to LUTs free configs, which I assume all ACES configs (reference, cg, studio) should in theory permit (otherwise add the missing transforms as BuitInTransform). Relying on a filesystem path would probably bring additional complexity and risks.
Update to the configs could follow a major / minor versioning scheme to communicate the backward compatibility, minor being only used when a bugfix is needed? The naming CreateDefault() looks good to me, maybe consider CreateBuiltIn() or CreateStandard() but that's a matter of taste.
Thanks @remia , that's a good suggestion, we will go with CreateFromBuiltinConfig(char*) rather than CreateDefault. I agree with your second paragraph too -- our first PR will only support fully built-in configs and not external configs on a specified path. For the versioning, we are planning on using the "basename" from the Configs working group as the identifier string, which has all of the relevant versions. For the special naming, we are thinking of following a URI-type style prefix (suggested by Kevin) such as "ocio://".