2023-08-29

August 29, 2023

Host: Carol Payne

Secretary: Doug Walker

Attendees: 

OCIO Configs Working Group Meeting Notes

• Built-in Configs Update

  • Doug: We are proceeding with the most recent files from Thomas to include in the OCIO 2.3.0 library release on Thursday.

  • Doug: I've updated our config release feature tracking spreadsheet based on where we wound up. The only planned feature that was not added was the SLog2 support.

  • This will update the most recent version of the built-in CG and Studio configs using the work from this group over the past year.

• Swapped Paint Roles

  • Doug: Mark Titchener commented on Slack that the updated configs (2.0 version) for older versions of OCIO (2.2 and earlier) that are being output from the generator all contain swapped paint roles. This is consistent with Issue #107, but not with the discussion at a previous meeting (which was reflected in the spreadsheet). I asked Mark to update the Issue #107 to reflect their requirements.
    
    

  • The group discussed how the configs version string should be handled in light of the various changes.
    
    

  • Kevin: Changing existing roles should imply a different configs version number, since it could be a breaking change. We should not release a 2.0 version of the configs that changes role assignment based on the OCIO part of the version string. Group: Agree.

  • Group decision: All 2.x config versions will have the swapped paint roles.  We updated the config release planning spreadsheet to reflect that.

  • We are not exactly sure what the wants are from the Foundry, once we have confirmation, we can work out how to best support.

• Version Naming Scheme

  • Doug: I created issue #104 several months ago to try and document the policy for incrementing the versions. We should try to update and finish that.

  • Lots of discussion around whether we should strategically release for maximum compatibility between config versions, or stay with a more traditional software approach of only the latest gets the updates unless a patch is requested

    • Ex: Display P3 Display colorspace - it's only built in to the 2.3 library, but should we still include it (not as a built-in) for older config versions?

    • Many different opinions here, a balance between what we can as a team commit to maintaining, and making the experience the best for end users

  • In general, people agreed that changing or removing should require a major version bump but that adding was safer and could potentially use a minor version bump.

  • We discussed the fact that in the 1.0 configs, the Ref Gamut Compression was added by bumping only the OCIO version, not the config version. Looking back, this may have been a mistake.

  • Kevin: I anticipate getting questions about why a given config version may contain a different set of features. Group agrees that we would probably like to increment the config version to reflect that.

  • Doug: We could name the upcoming release for OCIO 2.3 with config version 2.1 to indicate that it has the Display P3 Display that is not in the OCIO 2.2 and earlier versions. Group: Yes, we prefer that to avoid the issue Kevin raises.

• What OCIO Versions will be in the Upcoming Release
  
  

  • Doug: For our upcoming release of the updated configs, what OCIO versions should be generated?
    
    

  • Kevin: The 2.1 release that included the Ref. Gamut Compression was significant. For people upgrading from OCIOv1 to OCIOv2, they will probably jump to 2.1 at the very least.

  • Group: We will not generate OCIO 2.0 versions of the configs.  Going forward we will aim to release for the upcoming VFX Platform year, the current year, and one year back.

• Reference Configs

  • Thomas: I will remove the reference role from the Reference configs.  Group: Agree.

• Updating the Config Version number for the 2.3.0 Release

  • Doug: I could update the version string by hand so that Thomas does not need to do an emergency update to the generator.  But the problem is the description has a Git commit hash, I would not be able to update that.  Should we remove that "generated by ..." line of the description?

  • Thomas: It's helpful to be able to know exactly which commit generated the file. Someone could go back and regenerate it.

  • Doug: I'm worried that once you do any remaining work on the generator and make a "final" configs release that people will compare to the commit hash of the config built into the 2.3.0 library and be confused/worried that they don't match.

  • Thomas: It has been useful during the development process but agree we could drop that.  I will remove that line from the generator.

  • Per the group discussion, Doug will manually update the config version of the new built-in configs PR #1836 from 2.0 to 2.1.