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).

"}}},{"type":"paragraph"}],"version":1}

2022-04-11