Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.
    • Michael: Currently nuke looses that flag on read
    • Doug: DisplayView Transform will do no-op if either space is data. Added an option to process it anyway. Implemented to handle display of data on HDR displays, etc. We track colorspace in flame.
    • Mark: Currently can choose how to merge metadata. Maybe something similar.
  • course:
    • Doiug: Will be good to get input from group.
  • File IO handling:
    • Doug: Discussion on Slack. Larry noticed parse color space from string wasn't working the same as v1. New getColorSpaceFromFilePath method. Does that work with v1 config? Did some research and found that the new method was not applying the parseColorSpaceFromString handling from v1 configs. We have a issue logged for that. Wrote up the recommendation for what apps should do in that issue. See proposal in issue #1398.
    • Mark: Would like Nuke to handoff as much of color  space decision as possible to OCIO config. Config is there to help make these decisions and extra implementation logic is then not needed.
    • Doug: In Maya trying to determine if we should look at filename at all. Users can choose a space in UI. If strict parsing is True, how do we indicate to user that the default or something else were chosen.
    • Michael: If strict parsing and no color space, should it not throw? 
    • douyg: It doesn't in the source.
    • Michael: That's right, it returns empty string. Color space in filename is useful when used.
    • Doug: Should also add to UX guide (talked about in v1 docs), if config can't be found, an internal default config can be enabled. Turns off color management. In a lot of apps, you dont 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 without config.
    • Mark: And showing a warning that a config couldn't be found.
    • Doug: Yes. And textures and other nodes keep current color spaces. Results in error indication in color space param, but doesn't prevent render.
    • Mark: In Nuke, viewer wont render, and no fallback to internal config. Nodes will errors, and warning that config not found.
    • Doug: Obvious in maya that an error has happened, but can see image through raw processing.
    • 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 case, a fallback, and provide alt solutions when that doesn't make sense. Different cases presented. Color critical or not.
    • Doug: Loading config could be separate 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.
    • Michael: In theory could use interchange spaces and builtins to handle special cases.
    • Doug: Yes, exactly.
  • Items for next meeting agenda:
    • Info


  • No labels