2022-04-11

April 11th, 2022

Host: Mark Titchener

Attendees: 

Joseph Goldstone - ARRI
Michael Dolan (TSC) - Epic Games
Doug Walker (TSC Chief Architect) - Autodesk
Mark Titchener (TSC) - Foundry
Evan Wilson - Blender Foundation
Zach Lewis - Method
Vy Phan
Charles Boileau

Apologies:

OCIO UX Working Group Meeting Notes

  • Technical writer proposal:

  •  

    • Michael - Establish scope for a small part of docs first rather than a larger part of the UX guide?

    • Doug - General docs has bigger barrier to entry e.g. GitHub pull requests etc

    • Mark - We could just get them to use an external doc and we could handle the pull requests.

    • Doug - Yeah, we could provide a markdown file and they could deliver a new markdown file.

    • Michael - Displays/Views as possible starting pointing for UX?

    • Michael - Part of me thinks UX guide should be in the general docs.

    • Zach - I agree, they all feed into each other seamlessly.

    • Doug - Maybe no point in transferring to Wiki first?

    • Michael - Confluence might have markdown/export plugin if we did.

    • Mark - I think I’d prefer to have the UX guide as part of the main docs. Keeps all of the information in one place.

    • Doug - Need to figure out next steps for documentation writer.

    • Doug - Tech writer isn’t going to have any knowledge, context. Number of days for them to learn and then write.

    • Zach - Perhaps start with search paths, something that requires less domain specific knowledge?

    • Doug - How much writing do we need to see to make a decision?

    • Michael - Search paths perhaps too easy? Won’t be a very long section.

    • Mark - Maybe make recommendations for improving existing sections eg Roles as part of the initial scope too?

    • Zach - rather than specific sections perhaps Explain Half domain LUT and allocation vars to see how they would describe this to a general audience.

    • Michael - This is more of a general doc topic though.

    • Michael - Maybe FileIO handling?

    • Michael - We should show them Siggraph course as a starting point.

    • Doug - Maybe starter project should be UX section of Siggraph transferred to a written document?

    • Zach - Great idea.

    • Mark - Agreed.

    • Evan - What’s part of the application process vs. an actual paid project?

    • Doug - Think there will be an interview process first, once we find someone we can get a quote and provide this along with the brief to the TAC for approval.Technical Writer Proposal:

    • Mark - Yeah the intention isn’t to get someone to do the initial project as part of the application process.

  • ocioview demo:

    • Michael - This is a demo of ocioview, a side project I’ve been working on.

      • I started off with PyOCIODisplay and shared this in as an example implementation for OCIO.

      • Have a more advanced version that I may share at some point. Initial aim was to keep the example simpler and not confuse with lots of features.

      • Lots of projects have viewing tools e.g. USD has usdview, OTIO has otioview, OIIO has iv etc.

      • Thought having a similar tool for OCIO would be useful.

      • Wanted to prototype this myself until I had something I was happy with that we could then iterate on as a group. Just to speed up the process.

      • Idea is to have the PyOCIODisplay viewer in the main part of the UI.

      • Below would be an inspector and to the right is the config editor.

      • Icons for scene-referred and display-referred spaces.

      • Icons are google open source material design.

      • Every time you make a change it stores a new version of the config.

      • There’s global connectivity between interfaces so you can reuse previously input items e.g. families.

      • Some conditional interfaces e.g. allocation

      • Transform stack in “From Reference” and “To Reference”

      • From Reference or To Reference is highlighted dependent on the colourspace selected.

      • Can add new transforms from a list and reorder them in the stack,

      • Idea is you could see these changes live in the viewer.

      • Inspector for seeing how something works e.g. setting file and viewing rules and seeing how these get resolved.

    • Everyone - Great work, really awesome tool 

    • Charles - If you’re working in VFX could it be customised to our needs?

    • Michael - Yep, it’s all Python and the source will be shared in the OCIO repository eventually.

    • Joseph - Great to see this implemented. I started a similar thing on paper 15 years ago.

      • It would be great if for a given source pixel you could step through the transform stack to debug e.g. where it gets clipped.

    • Michael - Like a call stack for the transform process?

    • Joseph - Yeah.

    • Zach - That would be a really nice feature.

    • Michael - I’ve been documenting my code, aiming to make it straight forward for others to collaborate. Some others have already expressed interest in contributing

    • Zach - Curious about your thoughts on adding the grading transforms, which are obviously complicated

    • Michael - Don’t think they’re out of reach. Bézier curve editor would be needed but I have one somewhere. Qt provides a lot of good building blocks for this kind of thing.

    • Doug - The grading transforms are Not specifically a bezier curve but it’s similar. The tangents aren’t intended to be edited in the same way as bezier. Better to just be single points.

    • Michael - Maybe OpenGL implementation would be better

    • Michael - I haven’t used OCIO apphelpers yet, would like to add these for menus.

    • Doug - Yeah these would be good. You could see how menus update as you make changes to categories for example.

    • Michael - Code for ocioview in my repo, just not the latest.

  • Items for next meeting agenda:

    • Updates on technical writer progress.

  • Actions:

    • Mark to create first draft of technical writer proposal and share with group. Aim to have this ready for review at the next OCIO TSC meeting (Monday 18th April).