Update color spaces to use new attributes

[doug-walker]

OCIO PR #2165 adds new color space attributes. This issue is to update the configs to set those attributes, specifically the interop_id and the amf_transform_ids. Not sure it makes sense to set the icc_profile_name attribute?

[doug-walker]

Here is a spreadsheet with my proposal for the Interop IDs to be used for the CG & Studio config color spaces. I have indicated where a namespace will be required, but the exact namespace is still TBD.

For color spaces that don't have CIF IDs, I chose strings that are currently aliases in the existing Studio config rather than trying to come up with new ones. (Please keep in mind that every Interop ID will need to exist as an alias as well.)

The spreadsheet was generated by taking the one used by the generator to build the Studio config, deleting some irrelevant columns, and adding columns for namespace and interop ID. I added some additional rows for color spaces that don't have explicit rows in the spreadsheet, due to the way the generator works.

You should be able to leave comments directly in the spreadsheet with your suggestions.

[doug-walker]

We need to determine what string to use for the namespace for the Interop ID for the above color spaces. There was some discussion about this during the TSC meeting today.

Based on that, it seems that rather than using the config name string, we should come up with a common string to be used for all color spaces built into the OCIO library. Kevin suggested "ocio" as one possible idea. I like that as a straight-forward and easy to use option. Or we could extend it to something like "ocio-configs"?

In any case, it seems like we should publish a spreadsheet with these names (similar to what we've done at the CIF, perhaps on the OCIO GitHub Wiki?) and keep them reserved. That way, people generating their own configs will be easily able to check the names OCIO is using, or has used, over time.

[KevinJW]

Looking at the none-CIF spaces in the spreadsheet I wondered if we should try to follow a similar structure in naming?

Should try to better match the used in the full interop ids so that if they should become interop ids then we would only have to drop the namespace?

should we use "_camera" for camera curves? or is "_scene" good enough

There are some inconsistencies between the naming of camera vendor spaces

lin_alexawide vs lin_awg4 - should it be lin_awg3

lin_bmd_widegamut_gen5 contains lots of underscores is this a problem for parsing (I know they should not need parsing)

I'm imagining a world where we have a new set of interop ids that are camera spaces that tools like Baselight or other transcoding tools could want to flag files as

[scoopxyz]

I would vote in favor of matching the CIFID convention as much as possible, it would be great to propose/promote them to CIFIDs in the future. HOWEVER, if that can't be guaranteed, it would be even worse to add yet another aliases that needs to be carried forward in perpetuity for no purpose.

I wouldn't add an additional Image State for camera curves, just because the colorimetry isn't defined doesn't remove the scene-referred definition of pixel intensity (in most cases I can think of).

ADX stands out more to me as an oddity. As the film un-rendering is explicit in the colorspace definition, I suppose scene referred is appropriate.

[doug-walker]

@KevinJW , @scoopxyz , thanks for the feedback. In response, I've added another column to the spreadsheet with a second option (strawman, subject to debate). As I mentioned, the first option uses aliases that have shipped in the ACES configs for several years. The second option are new strings that attempt to follow the structure of the CIF IDs. If we adopt the second option, these would become additional aliases.

[carolalynn]

I like the idea of starting to standardize around the interop id naming conventions. And if we start now, it gives us wiggle room to test and assess while they are still just aliases, and make adjustments as needed. @doug-walker 's proposed names in the second column make sense to me - I also would keep _scene for camera spaces.