2022-05-30

May 30, 2022

Host: Carol Payne (TSC Chair) - Netflix

Secretary: Mark Titchener (TSC) - Foundry

Attendees:

Rémi Achard (TSC) - DNEG

Mei Chu (TSC) - Sony Pictures Imageworks

Sean Cooper (TSC ACES TAC Rep) - ARRI

Carol Payne (TSC Chair) - Netflix

Mark Titchener (TSC) - Foundry

Doug Walker (TSC Chief Architect) - Autodesk

Apologies:

OCIO TSC Meeting Notes

2.0.x and 2.1.x releases (Doug):
- Our last release was in mid December 2021 (2.1.1).
- Talked about doing a patch release to roll in most recent critical bug fixes. Perhaps the time to do this is now?
- RB-2.0 will become 2.0.4.
  - https://github.com/AcademySoftwareFoundation/OpenColorIO/commits/RB-2.0
  - 2 Python enhancements and a fix for a half-domain Lut1D issue.
- RB-2.1 will become 2.1.2.
  - https://github.com/AcademySoftwareFoundation/OpenColorIO/commits/RB-2.1
  - Includes the 2.0.4 fixes plus a few more e.g. build system and unit testing fixes.
- Looking at the commits in main, I don' think there's anything else that needs to go in.
- One more PR for each branch to take the dev suffix out of the version name.
- Does anyone have an additional suggestions?
- Remi - What about the grading related bug reported by Liam, should we include a fix for that?
- Doug - It would be nice to have but I don't think a lot of people will run into it. Request from product team to have a new release and would ideally like it sooner rather than later.
- Mark - Yes we have some time scheduled for a library update and would like to use 2.0.4 if possible.
- Mark - Would we need to include the grading fix in 2.0.x and 2.1.x?
- Doug - Yes, I think anything that’s fixing rendering should go into the currently supported release branches.
- Carol - Is there a fix yet?
- Remi - No. It's not started.
- Carol - Perhaps best to go ahead with patch releases now and Liam can test the fix in main. It can then be rolled into a future relase.
- Doug - OK, we'll go ahead and create the releases some time this week.
Support for OpenEXR to build additional apps (Remi)
- https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/1637
- I've continued with the work Michael Dolan started.
- Using OpenEXR instead of OpenImageIO to build ociolutimage, ocioconvert, ociodisplay and ocioperf.
- I've provided the option to use OIIO if you want to, the reason being it's required for some things e.g. GPU / OSL.
- The PR is open and I still have a few questions.
- The first is related to the complexity of the image class we have. ocioconvert --croptofull and --ch are much harder to implement in OpenEXR so they are only supported with OIIO. Should we consider dropping this functionality and pointing users towards oiiotool instead?
- I've made it so that we search for OIIO first, then for OpenEXR if neither are found and BUILD_APPS is set to missing or all then it will try to build OpenEXR automatically, like we do for other libraries.
  - Should we have an explicit flag for specifying OpenEXR? It might be useful for more complex package management?
- Doug - Cool! Nice feature! This will make a lot of people happy.
  - I think it's ok to send people towards oiiotool for that additional functionality.
  - A direct path to use OpenEXR could be useful.
- Carol - This is great! I also agree we can point people towards oiiotool for additional funcitionality.
  - I would like to send the PR over to Larry Gritz for review. Especially if we are going to suggest sending people his way. He might also have thoughts on the build process/options.
  - I would also like Mark Boorer to take a look.
  - Not sure if we need an explicit flag or not.
- Doug - The current path sounds user friendly for people less experienced with build processes i.e. fallback to building OpenEXR automatcally.
- Remi - Also worth noting I've removed support for OpenEXR 2 in this PR.
- Carol - Thanks for the work Remi, very excited for this!
Choice of hash function for caching (Remi):
- https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1645
- We use the cache more intensively in OCIO 2.
- Found the MD5 algorithm is quite slow e.g. when hashing a 65 3DLUT.
- I tried a non-cryptographic hashing algorithm (xxHash) which resulted in a 10-15x speed improvement.
- Perhaps a good time to migrate from MD5 to something else?
- Anyone have an opinion on this?
- I can create a PR but wondered how people would feel about another library in the build?
  - I picked xxHash for my tests as it's header only and is still maintained.
- Perhaps another for Mark Boorer and Larry Gritz to review.
- Carol - Sounds great and your logic seems reasonable.
  - We could also reach out to John at The Linux Foundation to see if anyone there has any recommendations.
  - Another option is talking to the other ASWF projects.
  - I'll take this to the next TAC.
- Doug - I think it's definitely worth doing. It's more a question of which lib to use and assessing the pros/cons.
  - I know people have differing opionons on header only libs.
  - Please go ahead and propose something in a PR and we can go from there.
- Remi - One more thing to mention is that performance could be particularly bad for a sequence of multiple shots that each have a CDL.
  - Should we add CDL as a dynamic parameter as some point?
- Doug - Yes I agree, this use case is one of the reasons why we created the legacy viewing pipeline, as we recognised we'd need a better way to support things like multi-shot timelines.
  - One solution could be breaking things down to the stuff before the look and the stuff after so that only the look changes.
- Remi - I was wondering about the overlap between grading primary and CDL?
- Doug - Yes the grading primary functionality supports CDL so we could convert to that and use those dynamic parameters.
Default configs:
- https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1621
- Hopefully have a PR up this week to include a default config.
Open Source Days / Siggraph organisation (Carol):
- We have a TAC / board meeting tomorrow to discuss when to have ASWF Open Source Days this year.
- Run up against a couple of snags e.g. wanted to partner with Siggraph but they have very concrete options for their programme this year, either fully in person or fully remote.
- So our options are:
  1. Associate with Siggraph and hold an in person event.
  2. Associate with Siggraph and hold a fully remote event.
  3. Not associate with Siggraph but hold an event during the same week at a different location in Vancouver.
  4. Not attempt to co-locate the event woth Siggraph/Vancouver at all and do it fully remote.
- What do folks think?
- Doug - If we do in person only during Siggraph can we still record it?
- Carol - Yes we can record it.
- Carol - My perspective is the Open Source Days are for general updates for the people who aren't following the projects regularly. So in my opinion the more folks that can participate the better. I expect Siggraph to have a lower turnout than normal.
- Doug - I agree. I would like to have an in person BoF for the people at Siggraph and keep the OSD separate.
- Doug - Any guidance from ASWF on OSD e.g. time, content expectations?
- Carol - 40 minutes, not further direction so think they'd be pretty flexible.
- Doug - Our previous thinking was the BoF would be Zoom style open discussion with the community. It would be nice if the OSD could be before that so we don't need to spend time doing that in the BoF.
- Carol - 100% agree. My preference would be OSD before Siggraph.
- Mark - I also agree. Running it during Siggraph it could get lost in the noise.
- Carol - Yeah, not sure how it's going to work. I know if I'm there in person I'm unlikely to be leaving to join a fully remote session.
- Carol - Thanks all I'll take this to the meeting tomorrow and report back later.
Items for next meeting agenda: