2021-05-24

May 24th, 2021

Host: Michael Dolan

Secretary: Mark Titchener

Attendees: 

OCIO UX Working Group Meeting Notes

• Misc.:

  • Michael: Doug and I are working on a course for Siggraph this year. This will be a deeper dive into OCIO providing technical insight for implementers rather than the usual project updates.

  • Michael: Welcome any UX / implementation suggestions for this course?

  • Doug: Yes, we are starting to make a list of OCIO features/workflows that require better documentation. Heard repeatedly from people that certain features in OCIO v1 were not implemented as well as they could have been due to a lack of examples in the documentation. So please do let us know if there’s anything you think we should include.

  • Michael: Would love to have an OCIO playbook of how different studios have solved problems. Talking with people often highlights things that we haven’t thought of.

  • Zach: I agree it would be really useful to have studios contribute to a Wiki or something similar. A lack of good examples is the number one thing I heard about OCIO before I got involved with OCIO v2.0.

  • Michael: We’re initially focussing on an implementation guide for app developers but these discussions making it clearer this would be really valuable for config authors too.

  • Evan: One thing I wanted to bring up was what Chris Brejon mentioned in Slack i.e. creating a spreadsheet of implementations in different apps. Difficult to maintain but would be a good snapshot of current approaches/issues.

  • Zach: HPD currently owns an old document, and he’d be happy for others to take it over. There’s also great conversations regarding After Effects and OCIO in Slack right now.

  • Michael: Would be good to have a way to store useful/important threads from Slack. Participation has ramped up and the free plan means messages/threads will not be around for long.

  • Evan: I find it hard to find the meeting notes in the Wiki. Could do with an easier way to access these.

  • Michael: We need to update our contributing documentation to reflect changes to using the Wiki. OpenEXR are using this now too.

• OCIO color management settings:

  • Chris: I’ve reviewed OCIO settings in different apps. Maya, Nuke, Substance Designer, Blender and Guerilla Render. I forgot to add Mari and can show that next time.
    From this I created a mockup as a proposal for in-app colour managements settings. Just to give us a starting point for discussion.
    
    I find it useful to have an indication env var label to show if it’s set.
    I’ve added a Look Transform dropdown, similar to Blender. I find it quite confusing that people mix views and looks. I’d prefer to have a separate look menu for selection.
    I thought it might be useful to show the roles in the UI so you don’t have to go into the config to see the mappings. Roles that are not used could be indicated in some way.
    I also added texture roles, similar to Mari e.g. texture_16int. Nuke doesn’t do this so there is often a clash between texturing and compositing.

  • Mark: Could showing the roles in the UI be misleading? i.e. if a user changes the selection then this no longer reflects the config.

  • Chris: I agree, it could be. One thing I haven’t shown in my mock-up is how Substance Designer handles this. The defaults are set based on the roles in the config and the resolved colourspace is initially greyed out in the UI. If a user chooses to override the default colorspace the drop down will no longer be greyed out to indicate this.

  • Michael: Thanks for creating this, it’s awesome. Regarding setting the roles in the UI e.g. Nuke uses the roles to set defaults but when a user changes the default I see it as overriding Nuke rather than overriding roles. It’s a slot that allows you to define a colourspace, which could be a role.

  • Chris: Nuke using the texture_paint role causes confusion for artists.

  • Chris: Substance designer forces us to use a specific working space e.g. scene_linear which isn’t always good for our workflow.

  • Deke: Yeah there are different needs for different apps.

  • Chris: Couldn’t we have defined roles for apps to follow?

  • Deke: Not easy e.g. Mari 16-bit is float, Photoshop 16-bit is integer. Nuke could be either.

  • Michael: Another comment on the mock-up is to be careful with naming, specifically the use of view and view transform, as they are now two separate things in OCIO v2.0.

  • Deke: Could we have a default set of roles but allow a namespace to allow for app specific overrides. Mari doesn’t have fallbacks?

  • Chris: Mari does have fallbacks for some settings - https://learn.foundry.com/mari/4.7/Content/user_guide/managing_colors/color_management.html

  • Deke: If you bring a PSD into Nuke you have to use a colourspace node in addition to OCIO to get it into the right place.

  • Michael: A namespace for roles could be really useful.

  • Chris: What exactly does this mean?

  • Michael: For example, nuke.role or mari.role, allowing the same role to be set differently in each app.

  • Doug: This is essentially what Mari has done. Is this an OCIO library requirement or just a recommendation to app developers?

  • Deke: It’s a recommendation to app developers.

  • Michael: Is a period supported in a colourspace names?

  • Doug: Would need to check.

  • Deke: Could be an underscore instead.

  • Chris: Back to looks, would it be a good thing to separate looks from views?

  • Michael: In big studio contexts this could be difficult i.e. views/looks are carefully managed. Some could be very specific and mixing and matching on the fly wouldn’t produce the correct result.

  • Deke: One thing mentioned before is to have a way to toggle looks on/off temporarily if needed but it would always revert back to the studio default.

  • Doug: I wonder what is it you are trying to solve with this?

  • Chris: I’m not entirely sure :)

  • We haven’t used looks a great deal in our animation pipeline but it seems overcomplicated to create all of the different view/look combinations required, e.g. tried this with all 87 ARRI looks and the viewer menus are massive! So my proposal is to simplify this and provide users with the option to combine views/looks on the fly in the DCC.

  • Doug: Think it’s a good idea for some use cases.

  • Deke: Do you have a specific use case here? What does your artist want to achieve?

  • Chris: A lighting artist friend who wants to switch between different looks for look dev and wanted to avoid the overhead of creating all the different combinations in the config and presenting the user with a huge menu to navigate.

  • Deke: A lot of the renderers are implementing this type of thing in their own way, e.g. Redshift ,OCIO is an option but off by default but there are lots of looks/effects that can be added post render for look development. A way to toggle different looks quickly in the UI would be beneficial for these workflows.

  • Chris: I was also thinking about ACES 2.0 and the potential for LMTs to become “first class citizens” (as mentioned by Kevin Wheatley) e.g a neutral look and could be useful to have a better way to toggle these in apps.

  • Michael: For studio features all views/looks are a curated list and carefully managed.

  • Deke: Agreed, probably not suitable for features but might be more useful in commercials

  • Chris: One last thing, I started creating a spreadsheet to capture different colour management settings across apps. I will share with the group.

  • Evan: Great! Happy to help fill it in.

  • Zach: Back to looks, shared views in OCIO 2.0 can contain a look which would remove some of the leg work in config authoring.

  • Doug: Config authors typically use the Python API to create so the overhead of generating a lot of views/displays isn’t too great. This seems like more of a case of how to best present these in a UI.

  • Doug: Shared views doesn’t have custom attributes but you can set <USE_DISPLAY_NAME> to simplify (see ACES reference config as an example) and also add looks as Zach said.

• Items for next meeting agenda:

  • Not discussed.