2021-02-12

Owned by Michael Dolan
Feb 22, 2021
5 min read

February 12, 2021

Host: Mark Titchener

Attendees:

  • [X] Michael Dolan (TSC Chair) - Epic Games

  • [X] Mark Titchener (TSC) - Foundry

  • [X] Doug Walker (TSC Chief Architect) - Autodesk

  • [X] Zach Lewis - Method

  • [X] Evan Wilson - Blender Foundation

OCIO UX Working Group Meeting Notes

  • General OCIO UX discussion:

    • Evan: Demo OCIOv2 config has been really helpful, thanks!

    • Michael: OCIO UX doc a scratch pad for the things I have encountered over the years of using OCIO both creating configs and integrating into apps. Some hidden things that maybe useful for people to know.

    • Mark: Gives us a good basis for prioritisation.

    • Doug: If we want to collaborate on this how should this work?

    • Michael: We could highlight things we think are important then convert this into an outline of concrete tasks we want to resolve. I've included a config author and app dev for each section. Should we focus on app developer first?

    • Doug: Really good list, perfect to set the basis for what we need to do.

    • Michael: We probably need some time to digest the doc.

    • Zach: I've Worked on OCIO docs some more since last meeting and happy to just start writing!

    • Michael: Mark/Doug Would be interested to know from your (Foundry/Autodesk) perspectives which things you think are reasonable for us to document/define.

    • Doug: We should definitely prioritise the items. I'll need to review the doc.

    • Mark: TODO, review this doc before next meeting (02-26-2021)

    • Michael: Could use colours to highlight priorities.

    • Evan: Found the ACES UX guidelines helpful, more end user focussed but could answer some of the questions we have e.g. layout of options. FYI I'm not officially representing Blender Foundation for this meeting but I'm currently working on improving colour management in Blender.

    • Doug: UX guidelines part of the ACES core documentation. Might be a bit too technical for artists. A lot of the naming has been followed in the ACES OCIO config.

    • Zach: TB13? explains the view transform paradigm. Perhaps ACES should reference OCIO as a lot of this is already defined?

    • Michael: Would be useful as part of a docs to have a block diagram for devs to understand the OCIO operations.

    • Evan: Yeah always thinking how do I explain concepts to end users.

    • Michael: Need to remember that applications will be used by high-end studios but also individuals/hobbyists.

    • Evan: Probably don't need a full on example but perhaps a high-level recommendation e.g. what are the core requirements vs. advanced options.

    • Michael: Totally agree, really critical to include this. I really like the ACES doc, it's technical but it's broken down well and nice to read.

    • Mark: We have some devs that are new to OpenColorIO so block diagrams would be useful.

    • Doug: Most of our devs have had previous experience, but diagrams would be really useful. Good for products that already use OCIO but also for those looking to implement it for the first time.

    • Doug: I'm chairing Common LUT Format (CLF) working group. We are creating an implementation guide, that starts from the very basics i.e. assumes you haven't read the CLF spec. A similar doc is being created for ACES Metadata File (AMF).

    • Doug: What we create should probably just belong in existing OCIO online documentation (ACES doesn't really have an equivalent, so it's all PDFs).

    • Michael: I would like to suggest Doug creates diagrams as the lead architect of OCIO v2. In the ACES wg how do these things get done e.g. assigning tasks.

    • Doug: Community projects so it's really hit and miss. Some people have time/interest to contribute but what's there is mostly written by myself and Scott Dyer.

    • Michael: ACES docs are very well put together. Using LaTeX?

    • Doug: Yes. They use LaTeX then create a PDF from that. We've been discussing WIP remaining in a Google Doc then using LaTeX for creating the final.

    • Zach: It's easier for people to contribute to a Google doc, don't have to learn something like LaTeX.

    • Michael: Should we use one doc for ideas and another for "finished" items?

    • Evan: Definitely two docs, would be very useful.

    • Zach: Doug's original docs/proposals contain a lot of great info. Perhaps we can repurpose some of that?

    • Doug: Yes we could definitely take some of that and reuse where possible. I'm happy to take a crack at some diagrams if people have specific ideas for these.

    • Michael: Some diagrams exist already from previous talks/presentations.

    • Zach: Really like the diagrams for the CLF transforms.

    • Doug: I did those for the Hollywood Post Alliance presentation. They can be found in the Digi Pro paper. Asked John Mertic (Linux Foundation) if we could have a dedicated place for docs but it's just shared from my Google Drive for now. (https://opencolorio.readthedocs.io/en/latest/concepts/publications/publications.html).

    • Michael: I'll share a doc for finished content and I've renamed the original for ideas (https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit?usp=sharing)

    • Doug: We can go from ideas > finished items doc > OCIO documentation.

    • Zach: We should advertise the doc.

    • Michael: I'll drop a note in Slack, to ask for feedback/ideas on priorities for UX.

    • Mark: Would be good to share with the wider community so they can share the pain points they've hit with OCIO implementation or the things they wish they knew at the start.

    • Michael: Definitely, I know Kevin Wheatley expressed an interest in contributing but is unable to join the meetings.

  • Meeting notes in the repo?:

    • Michael: Not sure we should push meeting notes into repo?

    • Doug: There is an ASWF wiki we could use?

    • Michael: Yes, and it's publicly accessible.

    • Zach: Doesn't GitHub have a Wiki, another option?

    • Michael: We are storing some other things in the ASWF space. Probably a conversation for another meeting but it's possible to use this.

    • Doug: Simplifies things to not have PRs for meeting notes. Should discuss this in a TSC meeting.

    • Evan: Grepped for "TODO" returns lots of meeting notes, so another +1 for moving notes out of the repository.

  • Discussion on PR #1307 (from Zach):

    • Doug: Zach, you submitted this PR but then closed?

    • Zach: It contained files that shouldn't be there. I'll create a cleaner PR.

    • Michael: To fix you could update your master and rebase.

    • Michael: I've found myself diving into private header files. Lots of great info there that would be really useful to pull out and make more public.

    • Zach: We should probably keep info in the public headers.

    • Doug: Agreed we'll leave the extra info in the headers.

    • Michael: Yes, it's useful for devs to get a quick understanding. Also has benefits for Python.

    • Zach: RST style refs get printed in docs resulting in noise.

    • Michael: We should used Doxygen style refs instead.

    • Michael: Run Doxygen on the headers and view HTML to see an example.

    • Zach: Shared screen to show difference between C++ and Python. In the former it's a link the latter there's no link.

    • Michael: Might be a limitation with my parsing code.

    • Doug: If Zach is removing the RST style anyway, that will help.