July 4, 2023
Host: Doug Walker
Secretary: Doug Walker
Attendees:
- Rémi Achard (TSC) - DNEG
- Mark Titchener (TSC) - Foundry
- Doug Walker (TSC Chief Architect) - Autodesk
Apologies:
- Carol Payne
OCIO Configs Working Group Meeting Notes
- Release planning:
- We discussed the config release planning spreadsheet. Due to the limited attendance today, we captured some questions to be answered by the bigger group.
- Question: How far back do we want to publish configs for. For example, if we are still making patches to the library RB-2.0 branch, does that mean we should be releasing configs for it? Keep in mind that the patches to RB-2.0 are only for important bug fixes, not new features. Perhaps that should be the same rule followed for the configs? (Currently there are no critical known bugs in the released configs.)
- Question: What should be the rules for updating the config version part of the config name? At a previous meeting we agreed that we should bump the major version when adding color spaces, but it would be nice to have a more complete set of rules written down. I logged this as issue #104.
- Note that the
cg-config-v1.0.0_aces-v1.3_ocio-v2.0.ocioandcg-config-v1.0.0_aces-v1.3_ocio-v2.1.ocioconfigs have the same config version number but only one has the ACES Reference Gamut Compression, so this was probably a mistake on our part not to increment that version number. - Ideally, we would have unit tests that do some kind of validation that the "contents" of two configs with a common config version number would be identical. (Understanding that we need to do some work to define what we mean by "contents". E.g., it should include the list of color spaces and looks but probably not differences in description strings.)
- Note that the
- Note that the only task that is time bound is to have the single CG and Studio config ready that will be built into the library. The other configs (e.g. for older OCIO versions) could be released later, upon demand.
- We discussed the config release planning spreadsheet. Due to the limited attendance today, we captured some questions to be answered by the bigger group.
- Usage of Built-in Transforms:
- In some of the color spaces (e.g. camera logs) the current configs contain individual transform operators even when a Built-in Transform is available.
- The benefit of that is that it is more apparent what math is being applied. The drawback is that it is not apparent at a glance whether the matrix coefficients and etc. are really the correct ones for that color space (e.g. a specific camera log) or whether they had been tampered with.
- The group today feels that it is somewhat preferable to use the Built-in Transforms whenever they exist. The proposal is to update the Python script to insert a Built-in Transform if it exists for the given OCIO version that the config is being built for. I logged this as issue #103.
- In some of the color spaces (e.g. camera logs) the current configs contain individual transform operators even when a Built-in Transform is available.
- Swapping of paint roles
- There has been an ongoing discussion of when to swap the matte_paint & texture_paint roles to their preferred values. It would be most convenient if this happens only for configs that have OCIO 2.3 as the version. In other words, the OCIO 2.0-2.2 configs should continue with the current arrangement. This implies that we should be incrementing the config version number to indicate that. The proposal is to use "config-v2.0.0" to indicate the new color spaces and "config-v2.1.0" to indicate the swapped paint roles.
Overview
Content Tools