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.
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:
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.