2024-04-15

April 15, 2024

Host: Doug Walker

Secretary: Doug Walker

Attendees:

Apologies:

• Carol Payne

• Remi Achard

• Mark Boorer

• Mei Chu

• Thomas Mansencal

OCIO TSC Meeting Notes

• Clang Format PR

  • Doug: Remi has a big PR applying Clang Format to the repo (modifies almost 500 files). Does anyone have any feedback?

  • Mark R.: I notice Remi has used Clang Format on/off comments to preserve some of the formatting of the AVX stuff, which is good.

• Core Color Space list

  • Doug: The next Color Interop Forum meeting is next Monday, the first project we will work on is the list of recommended core color spaces. It is likely that this list will become reserved names in OCIO that may not be redefined by config authors. The initial proposal for these names are the dozen spaces identified by MaterialX. Any thoughts?

  • Sean: I don't like the idea of essentially claiming namespace with configs in the wild that may use these names. Doug: Agree, maybe this could only apply to config files of 2.4 or higher?
    
    

  • Sean: It would be nice if the naming scheme followed a consistent pattern. Most of the dozen are <Transfer-Function>_<Primaries>, but not all. Would be nice to be more consistent. Mark T.: Yes, I had the same thought, was looking for a pattern.

  • Sean: Does this encourage lazy behavior by developers? For example, encourage them to ignore the user's config and just use srgb_texture for everything? The scene_linear role allows developers to be lazy, but in a good way since the config author keeps control by setting it to the color space they want. Not sure that would be the case here. Would srgb_texture always be an available color space, even if the config author did not include it? (In other words, available as an alias, even if it's not in user-facing menus.) Doug: It's a good point, we want to be wary of that. My opinion is that these color spaces would not be possible to override, but they would not be available in a config unless the config author included them. But we need to have that discussion within the Interop Forum to get the feedback from MaterialX, USD, etc. That said, keep in mind, that OCIO already offers srgb_texture in the built-in configs, so it is already available to developers and the public API already allows using it in connection with a user's config.
    
    

  • Mark R.: If it eventually turns out that they are always available, perhaps allow the config author to disable them, at least from being user-facing. Doug: Agree, we need to try and give the config author as much control as possible.

  • Sean: We should perhaps give some thought to how to communicate the changes to app developers.

  • Sean: srgb_texture is ambiguous in comparison to most of the other names, it's not immediately clear what it consists of.

  • Doug: What about the question of what color spaces should be on the list, do people think it's too many, too few, what would you change? Some of the MaterialX spaces are not encountered often in VFX.

  • Sean: Yes, some of these are definitely not widely used, we should slim the list down to the bare essentials.

• New PR related to minizip/zlib build order

  • Doug: Has anyone looked at PR #1965? Mark R.: It's not immediately clear why it's needed, doesn't the minizip-ng config already identify zlib as a dependency? Group: Would be helpful to get more info.

• Website certificate

  • Doug: I was looking through the recently closed issues and just wanted to ensure issue #669 was solved. Mark T.: Looking at "whois opencolorio.org" it's registered to the Linux Foundation. Mark R.: Clicking the lock next to the address in my browser, it looks like the certificate is being updated regularly. Group: Yes, the issue may be closed.

• Windows build issues

  • Doug: There are a number of threads on Slack about people having problems building on Windows, if anyone has expertise, please chime in.

  • Mark R.: I don't use the provided bat files, I use CMake, which comes with Visual Studio. That downloads and installs dependencies, similar to Linux.

• Review of the To Close issues

  • Doug: Carol has gone through the issue backlog and assigned the To Close label to issues that look like they should probably be closed. We will try to review a few at future meetings, but if anyone sees any they could close immediately, please do so. Mark T.: I see a few that are Foundry related, I will take an action item to review those.