2023-05-09

Owned by doug walker
May 09, 2023
4 min read

May 9, 2023

Host: Doug Walker

Secretary: Doug Walker

Attendees: 

Doug Walker (TSC Chief Architect) - Autodesk
Thomas Mansencal (TSC) - WetaFX
Kevin Wheatley (TSC) - Framestore
HP Duiker - Apple
David Krikorian - Apple

Apologies:

  • Carol Payne

OCIO Configs Working Group Meeting Notes

  • Display P3 texture space

    • Doug: We agreed at the last meeting to add a Display P3 texture space.  Need to finalize the name, aliases, and family.  We should look at the precedent of the existing "sRGB Encoded AP1 - Texture" and "Linear - P3-D65".  My suggestion is to use "sRGB Encoded P3-D65 - Texture".

    • HP: The "encoded" part is not ideal.  That was to avoid confusion with other sRGB spaces?  Thomas: Yes

    • Kevin/Thomas/Doug: The thought process for aliases is to support the official name and the short name from the previous config and to sometimes add a new alias if the official name changes.  But we are trying to keep it to a quite limited set, we certainly have not been adding all variations of that color space name that are used at various facilities. 

    • The group discussed various options for aliases and wound up with: [srgb_encoded_p3d65_tx, srgb_p3d65, srgb_displayp3, sRGB Display P3], as the list to post on GitHub for community feedback.

    • HP: We have feedback from artists that they would rather have the texture spaces in an "Input/Texture" menu hierarchy rather than under "Utility".

    • David: Artists feel there are too many spaces, want to easily have just the set that are appropriate for texturing.

    • Kevin/Doug: That is actually what the "categories" feature is for.  HP: What would be an example of an app that supports that?  Doug: Maya.

    • Doug: The proposal may want to recommend a category string ("texture"?) to be added to all color spaces appropriate for the type of artist you are thinking of.  The categories attribute may contain any number of strings.

    • Doug: What do people think about using "Input/Texture" rather than "Utility" for the family?  From my point of view, this is not something that could be done only to the Display P3 texture space, it would need to happen to all similar spaces.  And please keep in mind that in the Studio config there are already a lot of "Input/<camera vendor>" family attributes.  So "Texture" would fall alongside "ARRI", "Sony", etc.

    • Kevin/Thomas: It's not an unreasonable suggestion.

    • Action Item: HP to write up the specific proposal.

  • Rec. 2020 texture space

    • Doug: HP had to leave to another call but Apple would like to add another texture space with Rec.2020 primaries and sRGB transfer function.  HP said that although the primaries and transfer function of it would be very similar to the existing sRGB encoded AP1 space, the difference in white point warrants its inclusion.  Any thoughts?

    • Kevin/Thomas: No strong objection. We use the existing AP1 texture space internally but could imagine others might want Rec.2020.

    • Thomas/Doug: However, one of the complaints about the previous configs was that they were too bloated with a variety of similar spaces.  A strong case should be made and put up for community feedback.

    • Kevin: It will be important to name it unambiguously since the differences between them may not be apparent visually.

    • Doug: Should it be added to both the CG and Studio config, or only the latter?  Group: No strong preference.

    • Doug: The official standards for Rec.2020 use a 2.4 gamma rather than an sRGB encoding.  Would that be more appropriate?

    • Kevin/Thomas: It would be more standards compliant, however, sometimes it's necessary to encode textures using the sRGB transfer function since it has special support on the GPU, whereas a 2.4 gamma does not.

    • Doug: Is that something that OCIO's GPU renderer should support?  Kevin/Thomas: No, it's a flag you set on the texture, so there's no straight-forward way to take advantage of it from OCIO.  It's more of a game-engine thing.

    • Thomas: https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_sRGB_decode.txt

    • Doug: OK, so it sounds like we would use the sRGB encoding rather than gamma 2.4, if the community agrees to adding a Rec.2020 space.

  • Linear P3-D65 aliases

    • David: We would like to add "lin_displayp3" and "Linear - DisplayP3" as aliases to the "Linear - P3-D65" color space.

    • Kevin/Thomas/Doug: Sounds reasonable.

    • David: And it would be helpful to change the family from "Utility" to "Input/Texture".  From the artist point of view, any of the inputs are textures, even if they're linear.

    • Kevin/Thomas/Doug: We're uncomfortable with that change.  It's probably OK for gamma-encoded texture spaces, but not for linear spaces.

  • Config Merging

    • Doug: I've made some changes to the Config Merging slide deck based on the input received from previous discussions.  Please see the second page of the Proposal section.  I've added the idea of a ".ociom" file format that would bring the benefits of the "#include" approach since the dependent configs could be specified in one text file and the merge would be performed automatically at run-time.  And a new attribute was added to disallow merging of a config.

    • Kevin: I'm worried about the extension of the config becoming significant since it has not been in the past.  For example, our configs often use a ".conf" extension (for historical reasons) and that works fine today.  Will it be possible to detect the difference by inspection of the file contents?

    • Doug: Yes, the OCIOM format would not start with the same header as a config, so it would be possible to immediately tell it's not a regular config.  However, OCIOZ support currently requires the .ocioz extension.  We'd have to decide if we want to support auto-detection of the new format.

    • Thomas: How would the merge feature remove things from a config?  We have scripts internally that do things like remove color spaces or displays.  Would be nice if the merge feature would do that.

    • Doug: Agreed, that seems like an important feature.  I'll add something about that to the slide deck.  In the slides, you'll see there is a link to the OCIO wiki where I've been posting examples.  It would be awesome if you could post an example of what you'd like to see supported.