2024-06-17

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

June 17, 2024

Host: Doug Walker

Secretary: Doug Walker

Attendees: 

Luca Fascione

Thomas Mansencal

Dennis Adams
Oleksiy Puzikov
Doug Walker
(sorry, did not capture the names of all attendees)

Apologies:

  • Carol Payne

ASWF Color Interop Forum Meeting Notes

  • Agenda

    • Doug provided an overview of the current project to define a set of core color spaces for interop of texture assets between OpenUSD, MaterialX, and OCIO.

  • Compact vs. UI Names

    • Doug: We've been having trouble coming to a consensus on what the short or compact name strings should be for the color spaces. But as a reminder, the goal of the project is to come up with both the compact name and a user-facing name for use in a UI. The compact name would be what is stored in the MaterialX and USD documents, but given that it's not what would be shown in menus, I'm trying to understand why there is so much controversy over the strings.

    • Luca: If it's true no one looks at these, why not call them one, two, three, four? Not being serious, but just trying to make the point either people look at them or they don't. 

    • Doug: It's a fair point, people may see these in path names or in arguments to command-line tools, so we do want the names to be as understandable as possible, given the length. But is that the only reason?

    • Luca: What I was saying last time is that I had thought tooling may need to unpack what these mean programatically. If the naming becomes too irregular, writing a simplistic script becomes a nightmare. Imagine writing a bash script that wants to find everything that's gamma 2.2. Something that's just a few lines of code.

    • Doug: If the expectation is that software would be able to parse the names and build a transform just from that, I'm not sure that should be a goal.

    • Luca: That's more than what I had in mind, I'm just thinking of doing something semantic-based rather than only value-based ... to handle those situations that always come up at the 11-th hour.

    • Thomas: Yeah, and that's why I came up with the scheme to define them programmatically. I have the same need as Luca. Imagine interchange between companies, it's simpler if it may be parsed programmatically.

    • Doug: That's assuming you don't have a config file to look them up in? Thomas: Yeah, potentially not, it's rare we get the config file from other vendors.

    • Oleksiy: Is it the compact or UI name that would be used in OpenEXR files? Doug: Any usage within a file format would typically be the compact name. Oleksiy: Imagine I need to look in 10,000 OpenEXR files and find out which one is gamma, I have the same requirement.

    • Doug: I wanted to briefly mention how to convert the strings to be shown in a UI. Even if the compact names are used in file formats, if values for those fields need to be shown in a UI, and a config file is available, the OCIO getCanonicalName function could be used to get the UI name from the compact name.

  • Color Spaces as a Network

    • Doug: Historically, color spaces are defined in isolation and this sometimes leads to confusion about how to convert them to other color spaces. The Rec.709 and sRGB specs are examples of that. Our initiative here is different in that we are defining a group of color spaces in relation to one another, with the connections between them.

    • Doug showed diagrams illustrating the contents of the Studio and CG configs for ACES that are built into the current OCIO library. This showed the "texture asset color spaces" in relation to the other spaces in the network.

    • Doug: The proposal is that our published recommendations would include a subset of the CG config that provides the transforms among the color spaces in the core set.

    • Thomas: I think it's important to keep the rendering spaces in mind as well. "Texture" might not be the best word to describe the set. We could say "Scene" maybe, but it's broader than just textures. Doug: I tried to draw the box to include some of the ACES and utility spaces, but you raise a good point.

    • Luca: Are things that are photographed that you use to make textures included? Like if we hire someone to shoot a lot of reference photography that is going to be clone-stamped into textures, those source images ought to be in a texture color space, but they might not, if you're precise about it. Are those included as texture color spaces?

    • Doug: We've been using this word "texture" as a short-hand, but it's certainly broader than that. Not only images, but single RGB values. Luca: The diffuse color of a material for example is essentially a one pixel texture, so it makes sense to be in a texture color space.

    • Oleksiy: Textures could come from a cinema camera, right? And there is AR/XR. Saying that cameras are not included may be too limiting.
      Doug: There has been interest in expanding this initiative to cover camera color spaces and etc. But we were intentionally trying to limit ourselves to just the spaces that tend to be used in MaterialX and USD as a more manageable starting point. But we are talking about spaces such as ACEScg, linear Rec.2020, etc. that are used for a lot of other purposes, so the word "texture" may be too limiting.

    • Thomas: Yeah, that's my issue with it. As an example, one problem with the current configs is that it's difficult to convert, for example, sRGB textures to a P3 display. It requires two nodes right now. One alternative would be to add a texture option for DisplayP3, but it wouldn't make sense to artists. I don't find the "- Texture" suffix super helpful since we're using it for purposes beyond that.

    • Oleksiy: Should we be standardizing the building blocks instead? A set of color temperatures and gammas, etc. and then giving this set of Lego blocks. We would define Rec.709, sRGB, etc. where we provide a specific configuration, but we leave the door open for it to be extendable. I'm thinking of composability of the system.

    • Doug: That suggestion comes up frequently, and there are certainly a lot of tools in various applications that allow artists to have a drop down menu of all of the pieces and people can mix and match. But the problem is that most artists don't necessarily have the background to know which combinations make sense. There is a big danger of people creating assets that are using combinations that don't make sense and are unusable anywhere else.

  • Naming Discussion

    • Doug: Let's transition to the spreadsheet we've been discussing and the naming details. I'm showing three sets of options. The first is where we started, where it's only appending a "_tx" suffix to the gamma-corrected spaces that would conflict with display-referred versions. 

    • Luca: Just to clarify, you're saying they don't have an S-curve with toe and shoulder but otherwise they're processed the same as the display-referred versions, correct? 

    • Doug: Yes (showing the position of the scene-referred and display-referred versions on the diagram of the built-in configs). Luca: So the view transform is included but the gamma is not. I'm saying this because in the last call some people didn't get that distinction. It's important we make this super clear and make sure everyone is caught up. Doug: Absolutely.

    • Thomas: Just to go back to the display conversion point, the reason it doesn't work currently in the built-in configs is because the display color spaces are inactive. Doug: You're right, in fact, I remember logging an issue on the configs repo about that awhile back.

    • Doug: Going back to the various naming options, the second option was based on Thomas's analytic proposal but adding image state. The third is based on the idea of this being a color space network and so all of the names would have a "_cg" suffix that is like a namespace for this network.

    • Thomas: And there is a fourth option to just not have a suffix. Or to only have a suffix for the display-referred ones. Doug: That's right. The reason that is not on the spreadsheet is because we discussed that option at the most recent OCIO TSC meeting and a number of us are very uncomfortable with using just "sRGB" to indicate something that is different from the spec (in other words to use the same equations but in a scene-referred context). But you're right, that is another possible option.

    • Thomas: Part of the objection to "sRGB_texture" was not necessarily about having a suffix, but that it was not applied consistently to the other spaces. For example, should the linear spaces such as lin_rec709 have it too?

    • Luca: The use of "_cg" as the suffix for the third option is not ideal, for example if I have a reference photo that I'm clone-stamping into a texture, the photo is not computer generated. Doug: Yes, fair point, we could choose a different suffix. Option 3 was where the suffix was a namespace for the collection of spaces, whereas in option 2, it indicated image state. 

    • Luca: I prefer the philosophy of option 2. As someone who has not been participating for years in these discussions, the image state is something clear that I can learn that doesn't carry the baggage of history. If you base it on a collection, it seems more arbitrary, what if another color space comes along? Whereas option 2 is more future proof since it's simply based on the characteristics.

    • Thomas: I feel the same as Luca, taking my blackbody simulation example, to convert from srgb_scene to ap1_scene, that makes sense. Better than converting srgb_texture to lin_ap1_cg, or something like that.

    • Doug: Thanks for the input, we definitely want to have something that is understandable to artists and others that are not color scientists. That's one of the reasons we set up this forum as something separate from the OCIO TSC, so we bring in people to reality check the results.

    • Thomas: If we take option 2, that meets your criteria, right Doug? You have the image state represented. Doug: Yes, that would work for me, and I believe it would work for the OCIO TSC. Thomas: And it meets the programmatic requirements that people asked for earlier in the meeting, you have transfer function and gamut. Maybe that could be our consensus here?

    • Luca: I like it, option 2 is super clear to me.

    • Doug: Any other thoughts from the group?

    • Oleksiy: The "data" and "unknown" spaces don't conform to the same three part format. It's not ideal, but it's ok. Luca: They are not really color spaces, so it would be hard to make them follow the same format. Oleksiy: Agreed.

    • Dennis: Why is the format "transfer function" then "primaries" rather than "primaries" then "transfer function"? The latter might work better in an alphabetically sorted list. It's a matter of precedence in terms of what is easily converted to something else, for example, it's easier to convert among spaces that all share the same primaries. And finally in terms of history, that's the way we've done it in our applications. 

    • Doug: Thomas did prototype both orderings in his tab of the spreadsheet. The reason Carol and I used "transfer function" then "primaries" for the proposal is because that is the convention that has always been used in the OCIO configs and that is the ordering used in the MaterialX names that we are updating. Furthermore, it is the convention that most of the cinema camera vendors use when naming their color spaces. Thomas: And it's the convention used in ACES. Dennis: That sounds reasonable, I withdraw the suggestion.

    • Luca: The sorting point is a good one. I like the suggestion Dennis made, but am ok following the existing precedent.

  • Color Spaces to Include

    • Doug: If there is no other discussion about the compact names, I'm wondering if people have comments about what color spaces should be included in the list. We had talked at a previous meeting about potentially dropping spaces like the gamma 1.8 or AdobeRGB ones that are not widely used. Jonathan had asked that we keep the AdobeRGB, but he's ok with dropping gamma 1.8. And there are a few more such as lin_rec2020 and srgb_ap1 that people have asked that we add.

    • Thomas: We had gotten a request last year in the OCIO ACES configs project to add a few spaces, which included some on the spreadsheet here, including AdobeRGB and ProPhotoRGB. We had said no at the time but they were just asking again last week actually.

    • Doug: Are people in favor of adding these?

    • Thomas: The Adobe apps are using both AdobeRGB and ProPhoto a lot. Adobe Camera Raw I think uses ProPhoto as a working space. Adding those two would help interop with what the Adobe stack would often export.

    • Luca: I want to ask a question, I know there are some, like the gamma 1.8 options that would have been common maybe 15 years ago but are not widely used now. But aside from that, what is stopping us from erring on the side of including more? Does it cause that much more work to support 15 rather than 5?

    • Doug: You're right, it's not much work. One of the reasons we were trying to trim is that we've gotten feedback on the OCIO side that the configs just have too many options. People find it overwhelming to have so many choices in the menus. Thomas: Yeah.

    • Doug: But we were talking at an earlier meeting about dealing with that by including the extra options but in the documentation indicating that we only recommend a specific subset. So that might help steer people towards the more preferred spaces.

    • Luca: Sounds good. Some of the items here I think are very uncommon, but things like AdobeRGB and ProPhoto do show up sometimes. Let's err on the side of including them.

  • Items for next meeting

    • Doug: We're almost at time. We should briefly discuss our deliverable for Siggraph. We said we were going to have a draft of the recommendations to share at Siggraph. I've started writing that and will hopefully be able to post a link to it on the Slack channel next week. It's formatted as a Google Doc, so you'll be able to comment on it with your suggestions. The goal for our next meeting will be to go through and review the comments people make. That will be our last meeting before Siggraph so we want to get the document ready to share, not as a final recommendation, but to circulate it for comments from the community.