Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

July 25, 2022

Host: Carol Payne

Secretary: Mark Titchener

Attendees:

  • Rémi Achard (TSC) - DNEG

  • Mark Boorer (TSC) - Industrial Light & Magic

  • Mei Chu (TSC) - Sony Pictures Imageworks

  • Sean Cooper (TSC ACES TAC Rep) - ARRI

  • Patrick Hodoul (TSC) - Autodesk

  • John Mertic - Academy Software Foundation / Linux Foundation

  • Carol Payne (TSC Chair) - Netflix

  • Mark Titchener (TSC) - Foundry

  • Carl Rand (TSC) - Weta Digital

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

  • Name - Organization

Apologies:

  • Michael Dolan (TSC) - Epic Games

OCIO TSC Meeting Notes

  • Technical Writer for UX guidelines:
    • Doug: See there have been some replies from the people we contacted. Primarily Ehi.
    • Carol: Yeah. I’ve also been talking off-thread with Kelvin. The third person we contacted is already booked up with work and is unavailable.
    • Mark T: I haven’t had a chance to take a look yet.
    • Carol: Seem’s like Ehi has transcribed the training video. Logical approach but not super detailed. She’s willing to meet with us and talk through it. Which I think is a good next step.
    • Doug: I’d also like to see a sample of writing from both the people still in the running.
    • Carol: Yeah, that’s a good idea. Feel free to reply and ask for anything further.
    • Carol: I think we’ll wait until after Siggraph to get back to this.
    • Carol: Related to this ASWF had a budget meeting recently and we’re actually in a deficit (primarily due to cost of Slack). Conversations going on to figuring out how we move forward.
    • Carol: As an open foundation I think budget should be visible to all but it’s currently only board members who have access.
      Anyway as a result we may have to push the tech writer hiring into next year and specifically include it in the budget.
    • Doug: Given the amount members contribute, I’d be surprised if it’s just Slack causing the overspend.
    • Carol: Amount we pay for Slack has drastically increased this year (unexpectedly). This is due to the number of users we now have.
    • Doug: I also recently noticed Slack will be changing its message retainment policy for free plans, from 10,000 messages to 90 days. For us (OCIO) this is probably a lot worse. I think we had a small enough amount of traffic to go back more than 90 days.
    • Carol: We may have to resort to archiving messages regularly. Thomas Mansencal does this for Colour Science. I think it’s fairly easy to do.
    • Carol: Will keep you updated on ASWF plan longer term but John Mertic said other foundations typically move form Slack due to prohibitive costs. We would, of course, prefer to keep Slack as most people use it already for their work.
    • Carol: Also still need to make a decision on whether OCIO moves over to the ASWF Slack. This will further increase user numbers (for ASWF) but would fix our only 90 days of messages problem. Our general channel has 500+ users but there’s probably some overlap with existing ASWF users.
    • Doug: I will reply to Ethi to say thanks for her proposal, ask for some more examples and explain the next steps.
    • Carol: Great, I’ll also speak to Kelvin to ask for a writing sample.
  • Open Source Days
    • Carol: Doug and I have been discussing this offline. I’ve got the presentation template and added a rough outline e.g. key topics I think we should cover.
    • Carol: Myself and Doug are down as speakers/presenters but this is not set in stone. We would welcome anyone else who would like to help (TSC member or not). I’d like to leave at least 10 mins at the end for Q&A which you could help with. Also nice to put faces to names of the people helping drive OCIO day to day.
    • Carol: The survey is out but only 5 responses in a week. Please help share the survey with your team/contacts if you can. Also feel free to fill it out yourself, if there’s some feedback you’d like to include.
    • Carol: OSD topics include what’s currently planned for OCIO 2.2. A general release timeline and the new OCIO ACES configs i.e. what we did, why and the announcement of the1.0 release.
    • Doug: There are also a number of topics related to 2.2 features that I’d like to get feedback on from the wider community e.g. compulsory interchange roles and OCIO in MaterialX and USD. I can create a GH issue for the latter to gather opinions.
    • Carol: Any other topics for OSD?
    • Mark B: I’ve missed a few meetings so been out of the loop. Are Siggraph BoF’s still virtual only?
    • Carol: Yeah, virtual only.
    • Mark B: Where’s the best place to find publicity info about OSD?
    • Carol: ASWF slack and there was also an email sent out. [Open Source Days 2022: Schedule](https://osd2022.sched.com/)
    • Doug: We are also planning to have an OCIO TSC / working group meeting. I’ve tentatively asked for a room on Wednesday afternoon. Plan is to have the working group meeting then go for a beer somewhere.
    • Carol: OCIO OSD presentation is Monday 8th August at 2:45 PDT. OSD presentations are spread across Monday and Tuesday.
    • Carol: Also don’t forget beers of a feather is on Monday night. It’s free but requires registration.
    • Carol: First to say that publicity for OSD has been short notice due to figuring out what to do around /with Siggraph. Any help we can give as TSC members to spread the word is appreciated.
      I’m concerned we might not get many folks who aren’t already in the know.
    • Carol: One win though is we will be able to record and distribute these outside of Siggraph.
  • ASWF license scan results
    • Doug: Received an email from Linux Foundation. They have software for scanning source files to search for problems/bad practices.
      One thing that’s been flagged for OCIO is a possible usage permission issue for a Spiderman image on our website (which is hosted in our repository).
      The image is used with permission but there is metadata that states it shouldn’t be copied/redistributed which of course happens each time someone forks the OCIO repo.
    • Any suggestions or volunteers to help fix this?
    • Carol: What are our options? Host the image somewhere else?
    • Doug: We could contact Sony Pictures Imageworks to further clarify the permissions.
    • Carol: Think I’d rather go back to SPI for confirmation and update the metadata on the image in the repo. I remember having a convo with SPI about this at some point, I will try to find it.
    • Doug: It’s not urgent but I can add an issue so we don’t lose track of it and then review after Siggraph.
    • Doug: Two weeks from today is Monday 8th, which is the first day of Siggraph and Open Source Days.
    • Carol: Yeah I think we’ll probably cancel the next OCIO TSC.
  • AOB?
    • Remi: Just wanted to ask for another review on my PRs for replacing OIIO with OpenEXR and also the changing the hashing mechanism.
    • Doug: I’ve reviewed but Patrick is on vacation until after Siggrpah, so we’d need someone else to review.
    • Remi: It’s not urgent (as they’re for OCIO 2.2) but they’ve been open for a while.
  • OCIO in MaterialX and USD
    • Doug: With regards to MaterialX and USD, both projects are thinking about colour Management. The former has had something for a while but they’d like to improve.
      Both have the notion of tagging something with a colourspace (string) that is intended to be looked up in a config.
      OCIO 2.0 introduced display/view transforms which requires two strings. This doesn’t fit neatly into these systems.
      I was thinking we could have a special syntax that could combine the display/view into one string. Thoughts?
    • Kevin: Immediate reaction is this doesn’t sound clean. We’re trying to shoehorn something that we’ve already decided isn’t a colorpsace into a colorspace. Color science aside it seems a bad idea from a computer science perspective.
    • Doug: This wouldn’t be a user facing thing.
    • Kevin: But a user or pipeline does need to pick something. And odds are high they might pick the wrong thing.
    • Carol: What are the use cases where these systems would need a display/view rather than just a colourspace?
    • Doug: Perhaps an inverse display/view transform to a texture file.
    • Mark B: They do have access to all colourspaces, just not display/view, right? So they could make a new colour space that includes what they need.
    • Doug: Yes if editing the config is an option. The use case is more that you’ve received a config and can’t edit it.
    • Kevin: You don’t want people to go through inversions that may not be a clean.
    • Carol: If there’s a need for this then adding another colourspace is probably best approach. Otherwise we should have a bigger conversation about how OCIO integrates with these packages (the sooner the better).
      We are doing similar things in the configs working group e.g. config URNs. We could perhaps get these things lined up to have a unique identifier that could contain display/view for their use.
    • Doug: They are typically storing a config name string (name property of the config rather than the filename of the config) that goes along with colourspace name, attempting to be a unique identifier
    • Remi: Once you have the syntax what do you propose? e.g. inject the display/view transform into a colourspace.
    • Doug: Yes, allow you to do a display/view transform using a colorspace transform.
    • Remi: We have the same issue for review internally. Sometimes bake colour into a file that we then want to invert later. Larger issue than just USD/MaterialX.
    • Mark B: We’re just making colorspaces that combine them and haven’t migrated to display/views yet.
    • Remi: Duplication, have to remember to display Seems a bit redundant but I agree it’s probably the way to do it now.
    • Doug: Yes comes up in file rules where you’d like to have string to string syntax. People creating/editing own configs do have a workaround i.e. add your own colourspaces.
    • Kevin: We selectively put ridiculously named colourspaces in because we know they’ll give reasonable inversions. Ones from a client probably not if you want to inverse these we use a different mechanism.
  • OCIO ACES configs
    • Doug: We want to get the ACES configs ready for release at Siggraph. We’ve shifted to working group meetings every week.
    • Carol: Next is tomorrow (July 26th) at noon PDT. This is an hour earlier than usual so it doesn’t clash with the ACES TAC. Next week it will revert to normal time.
    • Doug: Please join if you want to help with anything either PR’s or contribution to discussion on naming conventions.
    • Carol: Doug doing great work getting camera CLFs in place. Camera vendors working to their own timeline so we need to push forward and create them ourselves with their approval.
    • Carol: Thomas has done lots of work on the ACES studio spreadsheet. Now turning colourspaces on programmatically. Link to those are in slack channel or meeting notes.
      Get feedback in now if you can but we do anticipate being able to make changes later.
    • Remi: Built-in config will be tied to a library version though right?
    • Carol: Yes.
    • Carol: First release will have a few external file dependencies that haven’t been built in.
    • Remi: External files are camera input transforms?
    • Carol: Yes.
    • Carol: Is ARRI LogC4 using an external file?
    • Doug: No, we can use the built-in OCIO CameraLogTransform to implement it.
    • Carol: So the ACES Studio config will probably ship with at least one external file dependency.
    • Doug:  I expect there will be more over time e.g. Phantom, GoPro etc.
  • No labels