2021-11-23

November 23, 2021

Host: Michael Dolan

Attendees: 

OCIO Config Working Group Meeting Notes

• Camera vendor update:

  • Carol: Have emails to setup meetings with some vendors. Will follow up after thanksgiving. Also have general email we can send to vendors asking for feedback on doc and process. What if vendors don't respond?

  • Thomas: Can leave their transforms out for now.

  • Carol: Had talked about being more limited in putting unpublished stuff in this config.

  • Thomas: Can provide recipe for adding missing transforms, so users can implement them.

  • Carol: Yes, can give links to locations with the data needed to implement.

  • Doug: ACES IDT working group also interested in expanding available IDTs, which should help.

• CG config PR discussion:

  • https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/pull/34 

  • TODO: Michael will rename "builtins" to "ocio", and add "OCIO.Utility" namespace to CLF file names.

    • Thomas: Contributors can have their organization name in file with namespace.

    • Doug: Right now not user facing since CLFs are embedded, but for studio config won't be able to do that, so namespace is important.

    • Michael: Also useful if these CLF files get copied around or used outside of OCIO.

  • Doug: Wrote python scripts to generate CLFs. Can use colour to generate matrices instead of current approach.

    • TODO: Doug will contribute CLF generation code to Michael's branch via PR

    • TODO: Thomas will contribute improved CLF to group transform implementation to Michael's branch via PR

  • Remove color spaces that have matching display color space implementation?

    • Doug: Default view transform is untonemapped, so can use display colorspace directly. Have other areas where we duplicated transform for ease of use.

    • Michael: Could we add alias to display colorspace with utility name for consistency?

    • Doug: Aliases don't show up in menus.

    • Michael: Think we could keep the spaces for clarity, and consistency with other utility "gamma" spaces.

    • Carol: Think taking them out would be good way to teach about OCIO v2, but when talking about inverse to things like sRGB texture, one of the most heavily used color spaces in config. Will either need to educate or leave it.

  • Do we want to clamp exponent transforms?

    • Doug: In v1 gamma was clamped unless value was 1. v2 options are clamp, linear, mirror, and pass through. Working group feedback was to not clamp by default. Clamp is added after transforms in output color spaces, to avoid display values beyond 1. In this case, mostly talking about input, and usually those are integer files, so a moot point.

    • Michael: Clamping can be problematic when roundtripping with out of range values. 

    • Carol: My gut is to not clamp, even if it's a change in behavior.

    • Thomas: Agree.

    • Kevin: Looks like OCIO clamps negatives in Exponent op.

    • Doug: That is used for v1 compatibility. v2 gamma op has clamp options, used in v2 transforms.

  • Clarifying gamma 2.2 AP1 space.

    • Doug: Added since ILM using it for MaterialX builtin color management. Wanted CG config to be superset of those spaces. Would be a good default config for MaterialX. When they are using AP1 primaries, not clear on the white point. Anyone here using that?

    • Kevin: We're using the D60(ish) white point

    • Carol, Thomas: Same. That's how it's implemented usually.

  • Reference/CG config views:

    • Doug: CG config using same views as ACES reference config. Some aren't useful for intended audience. Can prune some.

    • Carol: Agree. Think we settled on keeping standard SDR and HDR 1000nit.

    • TODO: Michael will update the Google spreadsheet to remove views, instead of updating CSV in repo.

    • Joseph: The 4000 nit space seems unneeded. Dolby Pulsar is only use case.

  • Working space options.

    • Doug: Traditionally config working space is locked down. For config like this, designed to be flexible and be used in different ways. Some may want to use linear Rec. 709 working space. Maybe want to work in linear P3-D65 space as a compromise between Rec. 709 and ACEScg. One way to work that is to set the working space category for those spaces in spreadsheet, and unset the rendering role. Proposing ACEScg, linear Rec. 709 , and linear P3-D65. Rendering role locks working space selection in Maya menu. Goes back to logic of roles. Are they requirement or recommendation?

    • Kevin: We use some roles as something you don't change away, and sometimes as a default hint. Usually more strict for working space.

    • Carol: In Nuke you can change the working space. I think the way Maya is doing that is useful. Depends on UX and use case.

    • Kevin: Could also see the desire to have multiple roles for different spaces in parts of pipeline. Can get complicated. Can satisfy a bunch of people reasonably well with one, but then others want different roles for different uses.

    • Carol: Could see usefulness in supporting multiple.

    • Kevin: Some studios have departments working in different spaces.

    • Carol: Think we should avoid that here.

    • Doug: Can control which to recommend with the category. Sounds like we want to set linear Rec.709 and ACEScg in working space category. Could let people add P3-D65 to category on own.

    • Michael: Do we follow Maya impl?

    • Kevin: Need to support multiple apps, which may not support it.

    • Doug: Not sure anyone else is using the rendering role automation yet, so would say not set the rendering role at this point.

    • Carol: Agree. Don't set rendering role yet. UX groups can decide different direction.

    • Kevin: Do we need docs around things you could do?

    • Thomas: Yes, would be good to document.

    • Kevin: Two items from today for docs, adding extra working colorspace, and how to set working spaces in maya, etc.

    • Carol: Haven't talked a ton about documentation yet for this repo. Could be another full topic for another discussion.

    • Doug: When we publish these, there should be a readme file.

    • Carol: Can link that to the OCIO docs too.

    • Thomas: We also generate documentation from code, and may already be on RTD.