2021-02-01
February 1, 2021
Host: Michael Dolan
Attendees:
[X] Mark Boorer (TSC) - Industrial Light & Magic
[X] Mei Chu (TSC) - Sony Pictures Imageworks
[X] Sean Cooper (TSC ACES TAC Rep) - ARRI
[X] Michael Dolan (TSC Chair) - Epic Games
[X] Patrick Hodoul (TSC) - Autodesk
[ ] John Mertic - Academy Software Foundation / Linux Foundation
[X] Carol Payne (TSC) - Netflix
[X] Mark Titchener (TSC) - Foundry
[X] Carl Rand (TSC) - Weta Digital
[X] Doug Walker (TSC Chief Architect) - Autodesk
[X] Kevin Wheatley (TSC) - Framestore
[X] Bernard Lefebvre - Autodesk
[X] Gonzalo Garramuno
[X] Remi Achard - DNEG
OCIO TSC Meeting Notes
Doug: Brief release update:
Doug: Released v2.0.0. Prepared PR to update docs with this status and additional v2 features. Following that merge, will send update to ocio-dev and ocio-user. Emily will help with ASWF blog post.
GSoC/D&I intern ideas. Volunteers for mentors?
Michael: Following up from last week. Do we want to pursue GSoC, and if so what project(s) would we propose?
Doug: Worth doing show of hands as to mentorship interest, and in reviewing applications. It's a time commitment.
Available: Doug, Patrick, Carol, Mark T, Mei, Michael.
Carol: Project ideas due by Feb 20th.
Michael: The ffmpeg project from last year might be good for the shorter GSoC project duration.
Kevin: Easier now since you can get floating point data in ffmpeg. Maybe not all inputs, but could refine the work.
Doug: That was the big unknown last year. Unclear if we could get float data.
Kevin: Improvements to OpenEXR reader and software scaler, so better float support.
Doug: Another option would be the OFX plugins.
TODO: Carol will update Wiki page with project ideas. Doug and others can help fill in details.
UX working group update
Michael: Had a good turn out and good discussion around how to have tangible results from the meeting. Group is committed to working on tasks between meetings to make progress. Reaching out to more software vendors (Adobe, SideFX, etc.) for possible participation.
Kevin: Can't commit to time slot. Have some thoughts about collecting use cases though. Good to have way to share those. Capture thoughts.
Doug: Can we change the time?
Kevin: Not a time issue, just full schedule.
Michael: You can add thoughts to this document, or in a GH issue: https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit?usp=sharing
How to get the package managers updated?
Doug: Would like to have this happen. So users don't need to build from source.
Patrick: Discussed vcpkg recently in GH issue and saw the process for updating it. Can try to find that.
Doug: Us pushing changes to those package managers, vs. asking others to do it.
Mark B: We have never owned those packages. Either send out release email and let maintainers update, or we might have to seek them out and update. Some are open and accept PRs, but Linux distro ones more closed group with specific maintainers.
Michael: Simran was looking into Conan. I can continue on pypi when I have time. I set up a project in dev pypi.
Patrick: Could get list of package managers in GH issue to see what we want to do. Volunteer, contact people, etc.
Carol: Can use checkable list in GH issues for this.
Michael: Ongoing CI working group discussion on package managers. Don't need to wait for that, but can perhaps lead it.
Patrick: Current GH issues exist for brew and vcpkg.
Doug: Has there been CI working group discussion about distribution of artifacts?
Michael: That has been in the long term plans, but has not been discussed much yet. Can bring it up at the meeting.
Headless GPU question:
Gonzolo: Ran into issue with oglhelpers opening window when running GPU renderer from commandline app on Ubuntu. Can this be avoided?
Doug: Can be avoided with GLX headless option.
Patrick: Think it needs to be called explicitly in CMake configuration. We have commandline tools using GPU without windows. If that doesn't work, log an issue and we will investigate.
Mark B: Started looking at headless mode. Concerned about it being a compile time flag. Anyone who wants to support a window, needs this off. For package manager, have to make one choice. Currently reference in core library in SystemMonitors. Should just affect runtime behavior, not compile time behavior.
Patrick: Could be a problem. Was done only for GPU tests on VM.
Mark: Might need to clearly comment it so people don't turn it off.
Patrick: Will investigate. Shouldn't need window for GPU commandline app. This flag is perhaps ambiguous, so might need to be renamed, or offer better explanation.
Display-based transform override question:
Mei: Can we override transforms based on display type. If display is sRGB for example, is there a way to override a color space to provide custom transform for that display only? Artists may not be aware of a LUT being baked in to image. Looking for mechanism to overrides this when transform for a different display type needed.
Kevin: We do something similar. Use specific view to contain special LUT. Can use that cancel out parts of transform.
Doug: New machinery in v2. Display color space. Also take a look at viewing rules. Config.getViews function receives display and color space and will filter views based on that. For certain color space, can limit to or reorder views for that.