2022-06-13 - OpenColorIO - Academy Software Foundation Wiki

New Built-in configs feature, PR #1659

Doug: We just contributed a new PR to implement the Built-in Configs (aka Default Configs) feature listed on the OCIO 2.2 Planning Board. Looking for feedback.
Doug: OCIO will have the Configs Working Group CG config built into the library itself. Design allows other configs to be added and multiple versions of a given config (e.g. as new ACES releases come out).
Kevin: The string with the config name is not ideal for applications to present to end-users.
Mark B: Could lean into the URI syntax and separate tokens with slashes: "ocio://v2.1.1/aces/v1.3/cg/cg-config-v0.1.0".
Doug: The naming was discussed in the Configs WG and Issue #45 on the Configs GitHub: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/issues/45.
Doug: We will look into adding a "user friendly" version of the string along the lines of what is proposed in Issue #45. This is the string that Thomas is using as the first line of the Description in the current config generator.

Tech Writer

Doug: I added a bit to the tech. writer brief based on our discussion at the UX Working Group last week. I think it's ready to be sent out.
Mark T: Looks good, I agree it's ready to go. Michael: Yes, ready to send it out.
Carol: I will send it out. To update the group, we have a list of three writers from John Mertic to help document the UX Guidelines and will send them a brief. We want to get a bid for the work along with how they would approach it. We will also set up a Zoom call with the candidates. We will be pioneering this for the ASWF, will allow the board to consider how to fund it, many other projects interested in this too.

OpenEXR support for apps, PR #1637

Carol: Looking for feedback on Remi's PR to solve the circular dependency problem. Larry provided some good comments. Mark B, we would like your thoughts on this.
Michael: The PR is still labelled Draft in GitHub, should that be changed to a regular PR? Group: Yes, probably.

Update processor caching, issue #1645

Carol: Remi has a PR, looking for feedback on it. It solves a performance issue he encountered in real-time playback scenarios.
Doug: I think the main thing for people to provide feedback on is the choice of hashing algorithm. There was a long thread on Slack where Larry and others commented on various options. Based on that, Remi is using xxhash, which is a very fast option and is header-only.
Mark B: Would the header be included in the repo or downloaded each time? I would prefer it be included in the repo.
Mark B: Debian, etc. sometimes objects to libs within libs, but perhaps will be ok if the symbols are hidden.
Mark B: Looking at xxhash, it is quite complicated, probably overkill for our needs.
Michael: Are there other creative alternatives to calculating a hash? E.g., use the file path for a LUT rather than hashing the contents.
Mark B: Using the pointer address would be one option. Looking at the PR, looks like it is converting objects to their Yaml representation and then hashing that. Could do some Xor-ing on that rather than calling a hash function.
Michael: I'd like to get Patrick's opinion on xxhash. We were in a similar situation regarding a fast float-to-string conversion and he wrote something to avoid needing to pull in an external library.
Zach: Does it include comments in LUT files as part of the hash? Kevin: The PR simply replaces md5, it doesn't affect what is included in the hash.
Michael: There is already a way for the client app to control the hashing: SetComputeHashFunction. Might be helpful for comparing alternatives. Default for LUTs uses the file path but this doesn't work if the LUT is only in memory or may change (e.g. in a version control system). This was a way around that.
Zach: I've been running into a problem recently where changes in the file were not picked up. That could explain my issue.
Carol: Please provide your feedback to Remi on what approach you prefer.

SIGGRAPH BoF and Open Source Days

Carol: OSD will be August 16 & 17 (Tues/Wed. after SIGGRAPH week). BoFs cannot be recorded and are virtual only. Not possible to have a live & virtual event at SIGGRAPH this year. The situation this year is not great. Lots of negative feedback has been provided to the SIGGRAPH organizers.
Carol: My thinking is to make our traditional project update available before OSD, run through it briefly during OSD but use the majority of our session for Q&A from the community. And then not do a BoF.
Kevin: I agree, there has been too much just "reading from slides" in previous sessions. Michael: I like the idea of providing materials ahead of time.
Group: Agree with the approach.
Kevin: The fact that OSD is not during SIGGRAPH week makes it difficult, need to find ways to market it.
Michael: Is the ASWF having a booth/table at the show? Carol: Will check.
Carol: Emily Olin is back at LF/ASWF, so that's great, she has lots of contacts and experience with us.
Carol: The ASWF is scheduling an additional unrecorded, in-person, mini-OSD the Monday afternoon of SIGGRAPH, followed by a Beers of a Feather event. This will help market the OSD event the following week and fill in somewhat for not having a BoF.
Carol: There has been discussion about how to work going forward. I can send people more detail if they are interested. Some of the problems are unique to Vancouver this year but others will likely persist when the conference is back in the US next year. If you have opinions, please let us know.
Carol: We could have an in-person TSC+ meeting for those that will be out there.
Group: That would be great. Michael: Reach out to Mario as he sometimes organizes color meetups in Vancouver. Carol: Will do.

OCIO Feature Matrix Draft

Carol: UX WG planning on doing a feature matrix to follow up on the work of Liam Collod. Will track version support as well as feature set. Looked at examples from OTIO, Nuke, etc. Mark T agreed to prototype something. Mark: Yes, will try to work on it this week.
Doug: This will be very helpful for some decisions that the Configs WG needs to make about color space naming, OCIO version, etc.

Remove meeting invites from ocio-dev?

Doug: The weekly meeting reminder emails to ocio-dev are really polluting the email list archive website. Makes it very difficult to browse previous conversations. Additionally, may be quite annoying to the majority of ocio-dev subscribers since only a small subset of the community attends the meetings. Should we try to stop these reminders going to all of ocio-dev?
Carol: The calendar and mailing list are linked right now in the ASWF system. But ASWF is moving to a new calendar system, so perhaps could be addressed as part of that. I could also see if I could go in and delete the invites from the mailing list archives.
Michael: Looking at the ocio-dev settings on the ASWF site, there is an option in the hash-tag section, looks like you can mute calendar reminder hash tags, this might solve the problem? Group: Please mute them and we'll see if that improves things.