2025-09-01 TSC Meeting notes

2.5.0 built-in configs

• Thomas has a PR implementing some of the 2.5.0 milestones

• Doug needs two reviewers for the PR to add mirrored displays

• Remi will make a proposal for what file_rules to set for the configs

• Doug will make a proposal for viewing rules and virtual display

Alternatives to built-in transforms

• Kevin pointed out that it might be useful to have a mechanism somewhere between FixedFunction and BuiltIn Transforms that would be useful for less-experienced users to add ACES Output Transforms, e.g. for an LED wall that is not quite P3 or has a different gamma.

• Thomas: Would it help to have a procedural approach driven by enums?

2.5.0 library

• Doug: We have a lot of PRs stacked up for inclusion in the 2.5.0 library release on September 30. Need help getting them reviewed. I’m available to provide a walk through or answer questions about the reviews, please DM me on Slack.

Generating Interop IDs

• Doug: We need a way to generate Interop IDs for the built-in configs for color spaces that are not in the CIF lists, for example the camera color spaces. This means they need a namespace prefix, what string should we use? The config name?

• Kevin: The config name is probably too fine-grained, it updates several times per year but the color spaces themselves don’t change that fast. Though we don’t know what changes any given vendor might make.

• Remi: Some of the color spaces are in both the Studio and CG configs, so config name is not ideal. Want the same namespace for both configs.

• Kevin: Of the three (Studio, CG, and Reference) none are a strict superset of the others. Perhaps use just “ocio” to refer to color spaces that have been built into the library? (And should probably list that as a reserved namespace token.)

• Doug will create an issue to discuss options.

• UPDATE: We will use this issue to discuss the new Interop IDs.

SDR/HDR mid-grey or brightness differences

• Doug provided a summary of the discussion from last Monday’s meeting:

  • There was agreement that a gain on the display luminance would be the preferrable method.

  • However, providing guidance for how to implement that needs more discussion. E.g., is it up to the DCC to implement by modifying the view transforms on their own, or should the config provide the explicit transforms? If the latter, would this be different view transforms (perhaps using categories, or active_views to switch modes), or some new functionality?

  • There was agreement that a solution to this would need to wait until after the 2.5.0 release.