ASWF TAC Meeting - 3 May, 2023

Video Conference Link

Voting member attendance

Premier member representatives

  • Bill Roberts - Adobe Inc.
  • Brian Cipriano - Google LLC / OpenCue
  • Cory Omand - The Walt Disney Studios
  • Eric Enderton - NVIDIA / DPEL
  • Eric Reinecke - Netflix
  • Esteban Papp - Amazon Web Services
  • Gordon Bradley - Autodesk
  • Greg Denton - Microsoft
  • Jean-Michel Dignard - Epic Games, Inc
  • Kimball Thurston - Weta Digital Ltd / Chairperson / raw2aces
  • Larry Gritz - Sony Pictures Imageworks
  • Mark Visser - Unity Technologies
  • Matthew Low - DreamWorks Animation
  • Michael B. Johnson - Apple Inc
  • Roy C Anthony - DNEG
  • Sean C McDuffee - Intel Corporation
  • Sean O’Connell - Advanced Micro Devices (AMD)

Project representatives

  • Carol Payne - OpenColorIO
  • Cary Phillips - OpenEXR
  • Chris Kulla - Open Shading Language
  • Jonathan Stone - MaterialX Representative
  • Joshua Minor - OpenTimelineIO
  • Ken Museth - OpenVDB

Industry representatives

  • Jean-Francois Panisset - Visual Effects Society

Other Attendees

  • David Morin, ASWF
  • John Mertic, LF
  • Emilly Olin, LF
  • JT Nelson, Pasadena Open Source consortium / SoCal Blender group
  • Stephen Mackenzie, NVIDIA/Rez
  • Doug Walker, Autodesk
  • Sergio Rojas, Different Dimensions
  • Nick Porcino, Pixar
  • Jean-Christophe Morin
  • Bill Ballew, Dreamworks
  • Deke Kincaid, Digital Domain
  • Lee Kerley, Sony Imageworks
  • Daniel Flehner Heen, Storm Studios
  • Ben Schofield
  • Mitch Prater, Laika
  • Scott Dyer, AMPAS
  • Spencer Stephens, MovieLabs

Apologies

*

Agenda

  • Updates
    • Next steps OpenImageIO proposal (Larry)
      • Several people came forward with names / placeholders for TSC, comfortable that people are springing into action.
      • Kimball: any other questions? Or do we have a motion to vote?
      • Eric Reinecke : propose, Carol, second
      • Lots of thumbs up, no oppose, no abstain.
      • Kimball: congratulations, motion accepted?
      • Larry: will follow up with John, lots of steps to be done
    • Dev Day - https://docs.google.com/document/d/1z0cVKfCGJhCpxTrBS1Sw3b6d-sDBSvFEoT1imD7dYYU/edit?usp=sharing
      • Carol: Deadline for comment on doc proposal: general proposal, plus list of questions to go out to companies. Good good feedback, but please feel free to add anything else to the document. Maybe we have time at the end of the meeting to discuss live? Unless someone has something urgent to ask?
      • Kimball: OK, sounds good. Do you feel you have the steps forward? Carol: I want everybody’s input, so if you have opinions, put them in the doc or send to me directly. Also if we greenlight and get enough interest, will need a second person from the TAC or two to help me run this. Will need someone to help co-run this, so think about whether you are interested. Have a couple of people from D&I working group committed to help. So people from TAC in conduction with D&I group and LF folks.
  • Diagram of the creative lifecycle of a production (Ben Schofield)
    • OpenTimelineIO Context for creatives slideset
    • OpenTimelineIO : Context for Creatives
      • Use cases & product roadmaps
    • Project adoption
      • Ranked by software maturity
      • Needs more context for usage in creative community
    • OpenTimelineIO
      • Engineering focus
      • Limited use cases in documentation
      • Signs of wider adoption
        • Sightings in the wild
        • Product…
    • Content lifecycle
      • Creative toolsets
      • Common workflows
      • Identify friction
      • Everyone can identify points of friction within these workflows
    • Trying to collate more use cases so we can remove more friction. Expand the list in RTD from 3 use cases to other cases where people are trying to use.
    • Some examples from #opentimelineio Slack, vendors starting to talk about how to incorporate OTIO in their products
    • Content lifecycle graph, where do these projects fit
    • Current focus on exchange of information between editors and VFX, and review process
    • People starting to build these links, for instance Rohit from BMD put something out there, spoke to NIgel at The Foundry. We’re starting to get interactions between projects and within product families.
    • Also a comment from BorisFX: usage within Netflix, editing and mastering using AAF for interchange results in data lost. “Thousands of dollars and workdays lost”
    • Trying to extract some use cases, build on them so we can explain them as an actual problem someone has today, and whether we can address with OTIO.
    • Get product roadmaps from vendors, how do those things work together.
    • Next steps
      • Collate us case in standard template
      • Identify business value to creatives
      • Confirm product interactions and roadmap
      • ASWF ecosystem project interactions
      • OTher industry initiatives: OSVP (camera metadata), IMF
        • Camera metadata is very valuable to VFX projects, lots of work going on there
        • IMF: distribution format, MXF is very good at doing video, audio and subtitle, but not great for other time driven metadata. An initiative on how to extend subtitle information and use it to carry other metadata, could be useful for advertising as well.
    • Meeting at NAB between vendors to share what they are doing
    • Want to get vendors to contribute. Vendors need to step forward, say how our products are using ASWF projects, do plug fests to validate interoperability. Also how do ASWF projects interact with each other.
    • Trying to get ideas from people, get people this out outside of the narrow group of code contributors, get wider adoption within industry.
    • Joshua: thank you for initiating this, we’re engineering focussed, looking at specific solutions, but we can’t answer business questions. Very useful, to other projects as well.
    • Ben: looking for other examples.
    • John: is there an existing WG working on this, or is this ad hoc at events. Ben: doing this within context of OTIO group, Josh has given me “airtime” on TSC, have had other individuals contributing ideas. Start of a journey, trying to create a book of these templates, share those out, and bring those to a later meeting. John: these are fantastic, we all know what these projects do, but people outside this “room”, not always. Where to projects fit in, what are they “competing” against…. This is fantastic, and we can definitely from our side help to support this, maybe have some kind of white paper, talk about the modern content lifecycle is as relates to open source.
    • Ben: helping NBCU with cloud workflows, how do you persuade the creative teams to try something new, one of the levers is having a big time or cost savings. As well as the technical function, the business need needs to be emphasized to drive adoption.
    • Carol: if we’re starting to add other ASWF projects into something like that, we may be surprised as what’s already integrated in software: OCIO, OSL… May want to expand the “VFX” box into all the intermediate steps. We can show people how all the ASWF projects fit into the lifecycle of content production, how many times they are used already, and opportunities for adoption. People may not realize what they are already using, Sometimes it becomes so common place they don’t realize it’s already in use.
    • Eric: at the NAB meeting, we talked about how OTIO may be growing in the future, for instant moving color metadata. We don’t plan to reinvent the work done by other projects, but how can we work seamlessly with other projects like OCIO.
    • Josh: show how projects can collaborate and interoperate. For instance color info in OpenEXR, not always clear how they interact. Documenting how things are already done, here’s how things have improved at a studio, can generate blog posts / white papers to show success stories. And show how non-VFX films may already be using these workflows, games, TV, lots of opportunities for ASWF projects to be used. Not trying to make a “sales pitch”, but it kind of is. We need to communicate the value of these projects in the right vocabulary. How much to document what’s been done, vs evangelize what could be done.
    • Ben: we should count any successes we can measure. Pushback is always “what I’m doing is already working”, but we can show how it can be done more efficiently. Eric: what people are doing with it, and what is more speculative in the future. But also the example from BorisFX: we want OTIO support and this is why. People who are asking for OTIO explicitly to solve a specific problem.
    • Kimball: we can use these maps to discover gaps where we don’t have a good answer, for instance a piece of metadata we can’t carry across.
    • Ben: will share the slides, want to keep the charts simple. John: could we place every ASWF project on this lifecycle? Carol: we have to split out and get more detailed for the VFX part, a lot of our projects are VFX specific and happen in specific steps of the VFX pipeline. This covers live action production, should we have a separate use case for animation? John: the big arrows at the top of the chart are very general, each box could be expanded.
    • Ben: it’s useful to try to map our projects to put them into context. Kimball: don’t want to weigh down the diagrams, but interchange and archival are a good part of the story since the code is open.
    • Eric: should OTIO become the blessed archival format has been discussed, some other approaches have already been used for that, but OTIO make sense. Ben: there’s the “raw” archive of WIPs, but also the final deliverable archive. Ideally you don’t want to lose anything.
    • Carol: archival also being discussed within the Academy group discussing consolidated archives. Kimball: we can point at ACES where they standardized as subset of EXR.
    • Eric E: Transfer between studios is also something that goes on and open standards are important to that.
    • Ben: have been working with MovieLabs folks for 15 years on related topics.
    • Ben: thank you everyone, will carry on with this effort. Joshua: will share more use case diagrams from our studio. This will be really useful
    • Show the ubiquity of ASWF documents. Eric R: we’re at a phase with OTIO where a bunch of vendors are starting to adopt us, there’s a lot of questions “how are people exactly using OTIO”, every vendor may not be familiar with every workflow. Some surprise at things like programmatically building timelines for instance. Creating more clarity has been useful for vendors, and they keep asking for me.
    • Eric E: I’m hearing 3 different motivations. 1- explain to consumers of OTIO what they might do with it. 2- explaining to vendors how customers want to use it. 3- explaining what ASWF projects are good for in general, and how it can save you money
    • Carol: non engineers / industry people would be the target. John: this is where people should put engineers on projects, this is a way that helps make it clear where people add value. People outside our group may not know the value of our projects, or may have their own in-house solution.
    • Carol: key element on how you onboard new project contributors, when people start they may not have the context of what the project is supposed to do. You can understand the code, but you may not understand the film or vfx pipeline.
    • Joshua: some companies / organizations have consulting dollars they could use to implement specific features
    • John: we have models in other industries, automotive industry had vendor / consumer model, they’ve developed new ones to help contributions
    • Eric: we should start small and build up. “Educating the whole world” is a big ask. Let’s concentrate first on specific use cases.
    • Kimball: map of Weta’s pipeline is interesting spaghetti. Joshua: would love to be able to share ours as well. Eric E: Could be a good DigiPro talk.
  • Project Sandboxing and how we scope to our principles
    • John: this came out of the the presentation a few weeks ago, the project didn’t have a lot of good fit at the sandbox level. What is the right sort of ingredients one would look at for a good sandbox project. Start to go down that road, the project may not have everything in place, but if they have a lot of the right ingredients, can be a good place to start.
    • Should we look at what it means to be a sandbox project, not so much the technical requirements, but the fit within the foundation.
    • Kimball: how do we make a document that gives people guidance as to what type of project we are looking for.
    • Kimball: for instance OIIO was a “no brainer”. Joshua: in DPEL, we made a wishlist we were hoping people would contribute, “wish there was a dataset for X-Y-Z”. So should we have a wishlist of “what we wish there was an open source solution for”. Or help identify projects that could become problems. Matthew L: where there are gaps of missing open source projects we could use. John: like a “good first issue” tag. Matthew Low: and where does it fit in this ecosystem, and the types of workflows we want to support. John: it’s not intended that a project comes in that’s competitive to another, don’t want one that’s in “competition”, so we want to fill gaps. Joshua: it’s fine if there’s some overlap, we have different playback tools? Not necessarily need to be a hard showstopper. John: some foundations do it both ways, some want minimal overlap, others are ok with competitive projects. What is the tolerance the group has for that. Larry: case by case basis, if another image format came in, we wound’t argue we already have OpenEXR. But if it’s an exact use case duplication, we may not want another color management system. We would “know it when we see it”. Carol: OpenAssetIO was a clear need that solved something that didn’t exist and needed to be solved. Or OIIO which is already widely adopted. Larry: developer resources are limited, there are only so many color scientists we can put on improving projects! There are other projects where you aren’t competing for resources.
    • Gordon: when we looked at Review&Playback, are we about to “knight” one of these, same for Package Management. It all comes back to how we set this foundation up, what’s in the best interest of open source for our industry. We can have 2 systems that are worth supporting, in other cases it would be dilution of effort. And in other cases we may be able to bring two projects together. It would be good for us to document how we need to assess it. At Autodesk open source project, not necessarily a binary test, answers tend to be a paragraph. Let’s understand why we are doing this, as opposed to just being “a home for a bunch of projects”. Eric E: it’s an investment / gamble, there’s a big component of “you know when you see it”.
    • JF: we should document why we would and would not accept a project.
    • John: This all sounds like the beginning of a document. Larry: still grappling with what it means to be a sandbox project. Difference between sandbox and incubating project should not be level of adoption. Sandbox means “it’s not done yet”, but it needs some time to grow. I don’t see sandbox as a “done” project that’s not as popular yet, that’s a “no”, not a “sandbox”. ORI is the perfect sandbox project, we know we want to build something, we need a place to build it, that’s the sandbox use case. But a project that’s coming in with little use, that’s not the use case. John: other foundations look at “is this project solving a problem that needs to be solved, and would the resources of this foundation help solve these problems”.
    • Gordon: we should document the success criteria to make it out of the sandbox phase, we may already have that in our template? Eric E: a criterion for this specific project? Gordon: yes, if we make a project a sandbox, we should document what would be needed to exit that stage. Eric E: is it allowed to fail? Incubation projects rarely fail, but sandbox projects could fail, that’s OK? Larry: we typically bring in foundational, long standing projects as incubating, just to fill the checklist… But I like the “too big to fail” aspect: that’s a good reason to accept a project, project is too important to the industry to allow it to fail.
    • John: would the ASWF have the resources to make it not fail.
    • Gordon: having criteria in order is useful, “too big to fail” is how we got ASWF together in the first place. Example was the NTP protocol. We can have other criteria, but that’s one we need to look at.
    • John: this is how I see other projects do this. Building the infrastructure for the project to be successful, but how can the TAC can have more of a guiding hand to help. Sandbox stage is where you try to get your stuff together. “Too big to fail” helps to make it successful
    • John: action item to take meeting notes and turn into an official document.

Notes