Page Comparison

...

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

Apologies:

• Zach Lewis
• Christophe Brejon

...

• 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: Currently nuke looses that flag on readDoug: DisplayView Transform 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 either space a colorspace is data by default. Added an option to process it anyway . Implemented to handle cases like display of data (like alpha channel) on HDR displays, etc. We track colorspace color space in flame.
  • Mark: Currently can choose how to merge metadata in Nuke. Maybe something similar .
  course:
  • Doiug: Will be good to get input from groupfor color spaces would be a solution.
• File IO handling:
  • Doug: Discussion on Slack. Larry noticed parse color space from string parseColorSpaceFromString wasn't working the same as v1. New 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 parseColorSpaceFromString 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 that issue. See proposal in issue #1398the issue.
  • Mark: Would like Nuke to handoff as much of color  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 filename 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 were was chosen.?
  • Michael: If strict parsing and no color space, should it not throw? 
  • douyg: 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 (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 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 without when there is no config.
  • Mark: And showing show a warning that a config couldn't be found.
  • Doug: Yes. And textures and other nodes keep current color spaces. Results In Maya this results in error indication in color space paramparams, but doesn't prevent render.
  • Mark: In Nuke, viewer wont won't render, and currently no fallback to internal config. Nodes will errorserror, and there is 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 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 special casesthat if they are implemented.
  • Doug: Yes, exactly.
  Items for next meeting agenda:
  • Info, that was part of the reasoning for the the interchange roles.