Add color space attribute to hold AMF transform IDs

[doug-walker]

Support for ACES Metadata File (AMF) requires that ACES transform IDs be stored with color spaces.

In the AMF prototype (available as a Python script in the shared directory), it looked for these IDs in the description field of a color space. Our current Studio configs automatically set the IDs into the description field to support this.

Unfortunately, more than one ID is needed per color space. It needs the ID for both directions (to and from ACES). It needs the ID for each Output Transform that makes use so a given display color space. And currently we are storing both the ACES and CLF IDs.

So some of the descriptions are now quite large, for example 38 lines of text and more than 4k characters. This interferes with the more common use of the description field, which is as a brief description of the color space that is suitable for use, for example, in tool-tips.

This was discussed at the TSC today and the decision was to create a new "amf_transform_ids" field for color spaces to hold this info. It is not anticipated that the formatting of the text would need to change. It would just move from the description to the new attribute.

[doug-walker]

@KelSolaar , you posted a comment in PR #2165 about AMF transform IDs. Sorry we didn't get to discuss it during the TSC meeting today. I thought I would redirect the conversation here since it is specific to AMF.

As you know, currently the AMF IDs are being put in the description field, which really interferes with applications that want just a simple description (e.g., for use in a tooltip next to color space names). My question for you is: are you objecting to putting the AMF transform IDs into the config at all, or are you asking that they be stored differently somehow? How would you prefer to match up color spaces in a config with the IDs in an AMF file?

One option would be to have a sidecar file, but that could easily get lost. Another option would be to build them into the library itself, but that doesn't allow users to add, e.g. vendor specific IDs that I know people are using with AMF. To me, putting them in the config with a dedicated field seems like the best solution, but I would like to get your ideas.

[KelSolaar]

I think (and prefer) that they should be in the file, but to preserve agnosticism, I only see two ways:

• We serialise them as we currently do in the description.
• We allow arbitrary metadata to be added.

[doug-walker]

For the record, the compromise that was agreed with @KelSolaar at the 2025-08-25 working group meeting is to add an amf_transform_id attribute but put it under a sub-group. Furthermore, there will be no bespoke getter/setter for it, it will use a generic attribute getter/setter that will be used for all attributes in the sub-group.

[doug-walker]

This is included in OCIO 2.5. In addition, this attribute has been added to View Transforms and Looks.