2024-06-10

Owned by doug walker
Last updated: Jun 10, 2024
5 min read

June 10, 2024

Host: Doug Walker

Secretary: Doug Walker

Attendees:

Rémi Achard (TSC) - DNEG
Mark Boorer (TSC) - Industrial Light & Magic
Mei Chu (TSC) - Sony Pictures Imageworks
Sean Cooper (TSC ACES TAC Rep) - ARRI
Michael Dolan (TSC) - Epic Games
Zach Lewis (TSC) - Method
Thomas Mansencal (TSC) - Weta FX 
Carol Payne (TSC Chair) - Netflix
Mark Titchener (TSC) - Foundry
Doug Walker (TSC Chief Architect) - Autodesk
Kevin Wheatley (TSC) - Framestore
Penne Lee - Intel

Apologies:

  • Carol Payne

  • Mark Boorer

OCIO TSC Meeting Notes

  • Developer Tools for Python

    • Mei: I've been looking at mypy and wondering if there's interest in using it to generate stubs for the Python binding. It would make it easier for developers writing Python scripts using the binding.

    • Thomas: It's a static typing tool that defines the types of arguments, which makes sense since the binding is mapping them to C++ types.

    • Mark: I've been using this related work from Luma. They've already done something similar for the OCIO Python binding.

    • Doug: Would this become part of the wheels?  Mei/Thomas: Yes.

    • Doug: What dependencies would this add to the project?  Mei: It would add mypy and whatever it depends on.

    • Action: Mei will create an Issue on GitHub with her proposal.

  • ACES 2 Support

    • Doug: Some of us were discussing at the ACES Output Transform WG last week how to take the R&D code and turn it into production code that's optimized for speed. Where do we stand with that?

    • Kevin: The goal of the ACES group was to come up with R&D code since it facilitated experimentation. Certainly Scott's CTL implementation pared away a lot of the experimental code that was not being used. So it's simpler than where we were, but it's not optimized. It's not clear that group would be able to turn it into production code due to lack of volunteers, but some of us are making efforts along those lines.

    • Kevin: I've been working on a simplified Blink script. Have gotten some big speed-ups. I plan to do some profiling.

    • Remi: I did some profiling on my C++ implementation. I didn't find any specific bottlenecks. There are basically four steps: RGB to JMh, Tone mapping, Gamut mapping, and JMh to RGB. The longest one is the tone-mapping, which takes about 40%, and the others are each about 20% of the time. I tried both a natural image and the ocioperf test target to see if that had an effect, the target took a little longer since it's doing more gamut mapping, but not a big effect. I think about 70% of the time is in the various power function calls.

    • Kevin: It's interesting because when I optimized the gamut mapping in my Blink script, I seemed to get an order of magnitude speed-up. That wouldn't be possible if it were only 20% of the overall compute. But maybe Remi has already optimized stuff that I have not in the Blink script.

    • Discussion: Both Remi and Kevin are pre-calculating the gamut and chroma mapping LUTs and are both pre-calculating the stuff needed for the RGB to JMh calculation. The difference in their findings remains unclear but may be due to the difference between running the algorithm on CPU vs. GPU.

    • Remi: I'm going to need to abandon the constexpr usage in my prototype. The official support of math functions in constexpr won't be until C++26. It's complicated because these may be affected by the floating-point flags in the CPU, so it's difficult to guarantee the same result between compilation and runtime. The Linux compiler I used supported it, unofficially, but now that I'm looking at other platforms, I'm realizing it will be too problematic. For example, it doesn't compile on Mac. Doug: How much of a blocker is it? Remi: It's not a blocker but will be more work to figure out the best approach and may incur a bigger setup cost. Currently I'm seeing about a 10ms cost to initialize the LUTs (though I need to double-check that). We don't want to have to do that every time, so need to figure out how to best store it or cache it, if it's not done as part of the compilation.

  • Color Space Naming

    • Doug: Here's a graphic I made (see below) to try and explain to people why our OCIO configs have both a display-referred and scene-referred version of sRGB. It's been a topic that has caused lots of confusion in the Color Interop Forum and nanoColor meetings, so I thought this might help.

    • Doug: Some of the people in those meetings have been requesting that we drop the "_texture" suffix and just call the scene-referred version "srgb". I'm uncomfortable about that because the official spec for sRGB is as a display-referred color space. Kevin: I'm uncomfortable as well with using just "srgb", people will misinterpret it. That's a worse option than srgb_texture.

    • Mark: I had the impression that they objected specifically to "texture" as being confusing but were open to using some other suffix.

    • Remi: Would we be changing the user-facing name too? Doug: I had not planned on it, but you raise a good point. Mark: I think we should keep them in sync.

    • Doug: In the proposal, we only have "_tx" on the ones where we may need to disambiguate a pair of similar color spaces. So it's not on any of the linear spaces such as ACEScg or linear Rec.709. We could take another approach and add "_tx" or some other suffix to the entire set of core texture asset color spaces, more as a namespace to indicate that it's part of that collection, rather than as a specific scene- vs. display-referred designation.

    • Kevin: Consistency is important. Mark: Yes, agree. But I'm starting to lean towards removing the suffix.

    • Thomas: But it doesn't makes sense to add "texture" everywhere, e.g. on the linear spaces.

    • Kevin: These compact names are trying to convey too much. Perhaps we shouldn't be trying to keep them so compact? Would people object to lengthening them? Doug: There are some use-cases people have cited that prefer short names such as using them in file/path names and using them as command-line arguments to tools such as oiiotool.

    • Mark: OCIO color spaces have other attributes such as family, encoding, categories. Perhaps we should leverage that more to hold the extra information?

    • Thomas: The ASWF Color Interop Forum project is really an effort to come up with an industry wide set of names, so it cannot rely too much on OCIO specific features.

    • Remi: What about going back to the analytic approach and explicitly put all the necessary information into the name. Kevin: Agree. Should not be trying to use short-cuts that will cause confusion.

    • Doug: Any suggestions for what text to use to indicate scene-referred and display-referred? Remi: Perhaps "scene" and "disp", though I've seen "disp" sometimes used to indicate a displacement map.

    • Kevin: Are there other things beyond image state that also need to be part of the names? I'm thinking workflow designations such as whether something has been neutralized or had a grade applied. Doug: For the specific set of core texture asset color spaces I think that would be out of scope, but not necessarily for a follow-on project to come up with a larger collection of names.