2021-05-10

Owned by Michael Dolan
Last updated: May 10, 2021 by doug walker
3 min read

May 10, 2021

Host: Mark Titchener

Secretary: Michael Dolan

Attendees: 

Michael Dolan (TSC Chair) - Epic Games
Mark Titchener (TSC) - Foundry
Doug Walker (TSC Chief Architect) - Autodesk

Apologies:

  • Zach Lewis

  • Christophe Brejon

OCIO UX Working Group Meeting Notes

  • OFX Update:

    • Michael: Updated the OFX nodes in PR based on previous meeting's conversation. Added "Swap color spaces" button, implemented a hybrid of the two proposed context param designs. Dynamic params are created for variables declared in config 'environment' section, and param values are stored persistently now. When loading a different config those params will not show up, but loading again with the previous config they will be restored. I will soon implement similar persistence for all choice params, to preserve selected color spaces, displays, etc. I have not found a good way to implement an in-node warning message yet. Popup warnings are working ok, and will only popup once for a given message. There is a string param mode for labels, but in my tests it was not honored by hosts.

  • 'isdata' input handling:

    • Mark: How would you handle multiple inputs where some are 'isdata', for merging operations, etc.

    • Michael: Tricky problem. You could track input color spaces, but at some point will have to choose one or the other.

    • Doug: ColorSpaceTransform and DisplayViewTransform will do no-op if a colorspace is data by default. Added an option to process it anyway to handle cases like display of data (like alpha channel) on HDR displays, etc. We track color space in flame.

    • Mark: Currently can choose how to merge metadata in Nuke. Maybe something similar for color spaces would be a solution.

  • File IO handling:

    • Doug: Discussion on Slack. Larry noticed parseColorSpaceFromString wasn't working the same as v1. OCIO v2 has new getColorSpaceFromFilePath method to replace it. Does that work with v1 config? Did some research and found that the new method was not applying the previous handling from v1 configs. We have a issue (#1398) logged for that with proposal. Wrote up the recommendation for what apps should do in the issue.

    • Mark: Would like Nuke to handoff as much color space decision making as possible to OCIO config. Config is there to help make these decisions and extra user implementation logic is then not needed.

    • Doug: In Maya trying to determine if we should look at strictparsing setting at all. Users can choose a color space in UI. If strict parsing is True, how do we indicate to user that the default or something else was chosen?

    • Michael: If strict parsing and no color space, should it not throw? 

    • Doug: That was mentioned in the v1 docs, but It doesn't throw in the source.

    • Michael: That's right, it returns empty string. Color space in filename is useful when used, good also for visibility when browsing files.

    • Doug: Should also add to UX guide, if config can't be found, an internal default config can be enabled. Turns off color management. In a lot of apps, you don't want a separate path for no color management. Easier in code to always assume there is a config. Being able to fallback on raw config is helpful. Want to be able to start app when there is no config.

    • Mark: And show a warning that a config couldn't be found.

    • Doug: Yes. And textures and other nodes keep current color spaces. In Maya this results in error indication in color space params, but doesn't prevent render.

    • Mark: In Nuke, viewer won't render, and currently no fallback to internal config. Nodes will error, and there is warning that config not found.

    • Michael: Maybe need to include section on error handling for each section.

    • Mark: Also dependent on product or use case. May need to lay out options for simple use case, a fallback, and provide alt solutions when that doesn't make sense. Different cases presented. Color critical or not, for example.

    • Doug: Loading config could be separate document section. Also think config interchange space can be moved to own section.

    • Mark: Could also auto-set output color space based on filepath.

    • Michael: I know this doc won't be ready in time for implementation, since the work is being done now, but good to talk through it together.

    • Mark: Will be a good guide going forward too, as we refine implementations.

    • Doug: And good for visibility in community, as to these conversations.

    • Mark: This will be an ideal implementation guideline.

    • Doug: One challenge is getting OCIO to play with other color libraries, like camera SDKs, since config may not have those spaces.

    • Michael: In theory could use interchange spaces and builtins to handle that if they are implemented.

    • Doug: Yes, exactly, that was part of the reasoning for the the interchange roles.