2022-04-11
April 11th, 2022
Host: Mark Titchener
Attendees:
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).