2021-04-12

April 12th, 2021

Host: Mark Titchener

Attendees: 

OCIO UX Working Group Meeting Notes

• Example OFX plugins:

  • Michael: Michael focusing on example OFX plugin. Should have benefits for this group.

  • Doug: If we pull down your fork waht will we see?

  • Michael: Just started with demo OFX plugin initially. Much further along now but it’s not in my fork yet.

  • Michael: OCIOColorSpace node is functional, will share when I have something more.

  • Michael: OFX neat but it’s not clear what you need to do for support in each application.

  • Jeroen: You’ll get to a point where you need to pick a path (host). Each add their own layers on top.

  • Michael: Is there an app that has a relatively vanilla OFX implementation?

  • Jeroen: Nuke is our go to for testing OFX plugins.

  • Michael: Can’t really use Nuke as it has OCIO in already and there will be a clashes.

  • Doug: Will definitely be useful to have this example plugin.

  • Michael: Plugins could be used in production but really intended as a reference implementation.

  • Michael: Nothing stopping us from using GPU path, it’ll just be more work.

• Colour pickers and the color_picking role:

  • Christophe: I've done some further investigation and had some discussion with other DCC developers.
    Had a look at Katana, can enable/disable display transform. Found it a bit weird at first to see picker moving when toggling display transform on/off (it’s on by default and I think most artists will use it this way. Possibly limited use cases for turning this off).
    Mari has a display referred picker.
    Houdini has a nice info dialog e.g. Output: P3D65, Pick: Ignore colorspace Input: ACEScg.
    For next time I could perhaps create a mockup for a basic colour picking panel.
    Would also like to investigate and present colour management settings across apps to show inconsistency e.g. roles displayed or not.

  • Chris: I would quite like to see app specific roles like Mari has e.g. nuke_working_role, substance_working_role.

  • Michael: In OCIO v1 there's a looks override in DisplayTransform.

  • Evan: Looks in the Blender default config are contrasts e.g. none, high, medium, very low.

  • Chris: I’ve been Looking at TCAM config (Baselight). Currently have to merge looks into a view. Would it be useful to have a separate look menu?

  • Michael: Some people requested to remove look override from OCIO.

  • Doug: Big VFX use of looks tends to be very complicated. It would be really useful to have an example config.

  • Deke: We can share a config. It would be nice to have the options to turn looks on and off but I would want it to reset when you’re done.

  • Deke: We limit looks by department e.g. texture would see less than comp.

  • Evan: The Blender use case is much simpler.

  • Deke: Use of looks for QC, bump contrast, check black levels etc. Would be nice to have a quick way to turn them on off without creating loads of views.

  • Michael: Definitely cases for view concatenation e.g. remove neutral grade then add shot grade. This is important.

  • Deke: Would like to have OCIO_ACTIVE_LOOKS to limit what is presented to users.

  • Doug: Would be great to have a feature request for this as we’ll probably need to extend the API.

  • Michael: If we could support this it would be interesting to expose the look syntax.

  • Deke: Back to the colour picker, in DD most of the artists know ACES values. They want to see the colour through the display transform but have the linear values. We're using ACEScg in Mari.

  • Evan: In Blender the values are linear but colour wheel is display referred.

  • Deke: Texture artists recently painting IOR which goes above one.

  • Michael: Chris would you be happy to put together a colour picker mock-up? Obvisouly each app looks different but defining a good foundation would be useful.

  • Chris: I would love to do that and also for the colour management settings.

  • Doug: Could you share link to slides?

  • Doug: Key insight is the confusion artists have with values, are they display referred or scene referred. There are valid use cases for both.

  • Michael: Concept art is essentially lit (painted). Director wants the colour to match.

  • Deke: We've had to deal with Pantone colours in the past.

  • Chris: I've started to do a minimum ACES OCIO config, most artists would expect ACEScg rather than sRGB, so we could have a discussion about this.

• Filtering and defaults for displays and views

  • Doug: Relates to new viewing rules feature. Problem is apps that need to work with media in a variety of spaces. Probably results in different views in the config.
    This allows the app to show display referred based or scene referred.

  • Chris: Another case could be AOVs e.g. normals you wouldn’t want a display transform.

  • Doug: Could add a preference to choose which OCIO display. When adding view options to a viewport if the app knows the image colourspace then we can show only those relevant.

  • Deke: We have HDR stuff coming through but we’re giving artists one HDR display. So seems useful.

  • Evan: Recently came up in Blender. 100% agree.

  • Michael: This is an important area of our document, viewing rules could be more confusing. Could imply different things but has a specific use case.

• ICC profiles

  • Doug: Using ICC profiles. Widely used on Mac/Windows and in popular apps e.g. Adobe.
    Requires a virtual_display section to be added to the config, can use SystemMonitors class.
    Adding a new display to the config that you’ve loaded in memory.
    Views that show up are the views from the virtual display section, after that they behave as normal displays/views.
    This is temporary thing, it’s just intended for the current session and shouldn’t be baked out

  • Michael: Might help to have minimum code example and diagram. As it’s taking into account system settings.

  • Doug: It would be useful to update the OCIO display sample app to include this.

  • Evan: The ociodisplay app is using the old GPU pipeline?

  • Michael: No, it's using the new pipeline.

  • Doug: Yes, using new GPU render pipeline, there are command line args to use in default or legacy mode. Changes the way the transforms are applied e.g. look override are using legacy viewing pipeline.

  • Michael: Had to explain this recently, as it’s not clear,

  • Michael: Overall the doc is looking good, probably half way there.