/
2025-04-14 TSC Meeting Notes

2025-04-14 TSC Meeting Notes

April 14, 2025

Host: Doug Walker

Secretary: Doug Walker

Attendees: 

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Remi Achard (TSC) - DNEG

  • Kevin Wheatley (TSC) - Framestore

  • Sean Cooper (TSC) - ARRI

  • Cuneyt Ozdas (TSC) - Autodesk

  • Joseph Goldstone

  • Alyssa Alexis

Apologies:

  • Carol Payne

  • Michael Dolan

  • Thomas Mansencal

  • Zach Lewis

OCIO TSC Meeting Notes

  • External References Feature – Issue #1975:

    • Doug: We’ve been discussing issue #1975 for a few meetings now. Both Adobe and NBC/Universal are quite interested in this. We should try to refine the design to a point where someone could start implementing this for inclusion in OCIO 2.5.

    • Doug: I put together some slides to guide the discussion. This started out as a method to identify an ICC profile, but the scope has expanded a lot to CICP and other types of external information.

    • https://docs.google.com/presentation/d/1k1vA_DS33_fah-j_lQczs4CTJvZVbXI_W7VBEm0h7-k/edit?usp=sharing

    • This is also related to the OpenEXR discussion we’ve been having, where we need to decide which string put in the EXR header for a color space, since it often would not be the user-facing name string. We had originally discussed OCIO automatically trying to determine a string, but Sean and others suggested it would be more robust for the config author to specify it.

    • Kevin: A big question is how much should we be validating and do we allow people to put in custom fields without recompiling the library.

    • Doug: Yes, exactly. In the last meeting Mark suggested it would reduce potential formatting errors if OCIO provides explicit getters and setters for certain pieces of information, such as CICP. But it could still be implemented under the hood as generic name/value pairs. But others suggested that we don’t want to validate strictly to H.273 since there is a delay between the CICP people use in practice and what makes it into a spec.

    • Doug: In the next slide I listed some extra types of information that came up.

    • Joseph: And I think Kevin had mentioned EDID. Kevin: And Windows has its own way of tagging buffers, and at some point Wayland as well.

    • Doug: So are we saying that we want to just allow free-form name/value pairs?

    • Kevin: Well the question is whether we’re trying to handle every possible source of weirdness and glue it together into one feature.

    • Joseph: And that was kind of what H.273 was trying to do. Everything is trying to wrap everything else, which is a drag. Is the tagging color space in your slide for other formats beyond EXR?

    • Doug: Yes. Kevin: It could be also for MaterialX, etc.

    • Sean: The proposal has the name of an ICC profile, but how to find the file? Doug: I had asked the same question to Cody. It sounds like for his use-case it could be put somewhere on the OCIO search_path. But in principle an application could look in other well-known places for it too.

    • Joseph: There are many other similar things people could ask for. NDI has color space metadata. There is SMPTE ST352 V-PID for SDI. And there is something like EDID going from host to display. The list never ends.

    • Doug: I wonder if we’re going about this in the wrong way. Many of these attributes are redundant. In other words, in my example slide, this is a Rec.2100-PQ color space. Once you know that, most of these other ones are just specific ways of signaling the same thing. Do we need to explicitly include all of them? Maybe it should be up to the application to know that mapping, for the ones it cares about?

    • Joseph: Right, and eliminating redundancy is good because if not, some of them may not all be consistent and then it’s confusing for the application to try to deal with that.

    • Kevin: There are kind of two separate things here: the things like what enum to use when tagging a buffer is immediately useful for displaying it; the second type are things to be used when tagging files or streams that may be exported later.

    • Kevin: If we’re just going to put some unique ID, then there will have to be some separate file with a dictionary of this information that lives alongside the config. Joseph: Ugh. Kevin: Yeah, so that’s the trade-off.

    • Kevin: Though the library could potentially still provide that, for most of these. Though one thing it probably can’t provide is the name of the ICC profile for tagging. The name may be different on various systems, I don’t think we can proscribe it.

    • Joseph: So does this apply to things coming in, or only going out?

    • Kevin: What we’ve said in previous meetings is only output, and we would use File Rules or some other mechanism to determine the input mapping. It’s not a 1:1 mapping. The example that came up was where people have images in different grading states. They may be all for use on a given display type, but they need to map to different color spaces.

    • Doug: If we know this is, for example, a Rec.2100 PQ color space, which of these could we derive from that information?

    • Kevin: Not the CICP unfortunately, as there are multiple CICP values used to tag a given color space in some cases. Doug: Is that just the 1-1-1 vs 1-2-1 issue? Kevin: We’ve run into additional ones unfortunately where a client requests an unusual value. Doug: Is it really OCIO’s job to be able to handle those edge cases though? Kevin: But that’s its job, if it’s just specifying a value to put in the file.

    • Kevin: You need narrow/full range as well. Doug: Most software seems to deal with that as a separate set of controls that aren’t connected to the OCIO config. Kevin: For ffmpeg for example, we would like to know what values to pass. Doug: So would a legal range flag indicate what the color space is or how you want ffmpeg to encode it? Kevin: It should describe what the color space is. So for example, if you have a 3D-LUT that provides narrow range, that’s how it would work.

    • Remi: Do you think this would only be used in display color spaces or would we allow it elsewhere? For example, when we write movie files we want to specify which view transform was used and there may be different options all using the same display. And some of the data you’ve listed, such as the max luminance value in the HDR metadata, would have to come from the view transform, the display would not know that (e.g., SDR simulation on an HDR display). Or D60 simulation on a D65 display, that would come from the view, not the display. Maybe there would be some accumulation process that looks at the display and view.

    • Kevin: I was thinking it would apply to non-display color spaces as well. But it’s an interesting question of how to bring in the view information.

    • Remi: Some cases we run into are complicated, where views or displays are inverted and then others applied. More thought would be needed how to handle those.

    • Doug: These attempts to describe arbitrary workflows with metadata get complex quite quickly. Maybe it’s not OCIO’s job to handle this and it’s more on the user and application.

    • Kevin: I would not consider the input color space, and the case of there only being an output color space is straight-forward, so the view + display is the interesting one.

    • Sean: Maybe we should make it a generic metadata container. If we do, we should also namespace the names to organize by studio and vendor in addition to the OCIO official ones. Should the values support different data types, or strings only?

    • Doug: I had been thinking strings only. Joseph: In EXR there are multiple data types and we’ve run into lens focus distance for example being encoded as a string by some vendors and a float by others.

    • Joseph: Also, be prepared for people trying to put binary encoded blobs. Kevin: Encoded as base64 or something similar.

    • Sean: But I think namespacing would help at least. Doug: Would it be like “ocio dot something”? Kevin: Perhaps it should be more of a Yaml approach where they are nested via indents.

    • Kevin: This reminds me of what happened with the roles, where we’ve wound up with a potentially very large number of values from vendors.

    • Sean: If it’s just a list of “random” stuff there is the issue of it becoming unreliable. And the other issue is if it’s optional it adds complexity if a piece of information may or may not be there. So maybe there needs to be a list of official entries to build trust.

    • Cuneyt: The ACES transform IDs being put in the description field of the current ACES configs is an example of the need to be able to store information in a well-structured way. It is quite confusing the way it is now, since these are no longer useful as pure descriptions. Doug: Yeah, that was done to support AMF but I agree it should be moved out of the description.

    • Kevin: With the namespace, it looks strange to have CICP and ICC under the OCIO namespace, it’s not clear how to interpret that. Sean: I would interpret it as ownership of the name key, not the value. In other words, it’s OCIO’s way of specifying the CICP data.

    • Remi: Should there be presets or a way of not having to enter all the values each time, which could be error prone? For example, if someone’s using the built-in display color spaces, it would be nice if they didn’t have to manually populate this long set of metadata values for it. The API could perhaps provide info for the built-ins transforms, if it’s missing. Kevin: As a default, and if it’s present then it’s an override.

    • Joseph: Thinking about the OpenEXR experience, once you allow free-form metadata, be prepared for a maze of twisty passages, all alike. It’s tough to keep people aligned on usage.

    • Kevin: As a crazy example, someone could create key/values with the XML that should be exported when writing an AMF file, all kinds of stuff like that.

    • Sean: But there aren’t that many people authoring config files, I think they will be well curated. I don’t think the library should prevent people from adding things they think are useful. The namespace should keep random stuff separate.

    • Doug: Should we create a separate issue for the final design of this or for the large topic of external metadata? Joseph/Sean: Yes, create a separate issue for the latter.

  • Config Archiving Enhancements:

    • Doug: Kevin, is your PR #1931 something you would like to get into OCIO 2.5?

    • Kevin: Yes, that would be great. It is not done, Remi and I were discussing aspects of how it should work. It would be helpful to get more input from people about the features they want.

    • Doug: I saw your recent commits added more compression options. Is that something you needed to add? The default was already best compression, is that so slow that anyone needs a faster method that compresses less? Kevin: It was easy to add, but it’s not essential, if people don’t think it’s useful it could be dropped.

    • Action Item for the group: Please add comments in PR #1931 regarding the feature set you would like to see for this.

  • Next Meeting:

    • Should we cancel the CIF and NanoColor meetings on Monday due to the Easter Monday holiday in Canada and Europe? Decision: Yes.

    • Next meeting will be the TSC meeting on the 28th.