Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

June 3, 2024

Host: Doug Walker

Secretary: Doug Walker

Attendees: 

  • Nick Porcino
  • Anders Langlands
  •  
  • Thomas Mansencal
  • Doug Walker
  • Cuneyt Ozdas
  • Jessica Wang
  •  
  • <Didn't capture the other attendees, sorry!>

Apologies:

  • Carol Payne
  • Jonathan Stone

OCIO nanoColor Working Group Meeting Notes

  • Plan for Siggraph:
    • Doug: Reviewed the plan, Cuneyt is working on a light-weight version of OCIO that includes the functionality of Nick's prototype. The ASWF Color Interop Forum is working on the list of core texture asset color spaces. We will be collaborating on a presentation about nanoColor for ASWF Open Source Days.
    • Anders: I'm planning a BoF (probably on Wednesday) on topics related to rendering interchange and will have some promotion of nanoColor there too.
  • Custom Color Spaces
    • Doug: The area that probably needs to most work right now is how custom color spaces will work. In Nick's prototype, there's a way of defining a custom color space using chromaticity coordinates and a gamma (or gamma and straight section). And there is similar functionality in OCIO (using a matrix rather than chromaticities).
    • Doug: Here's an example of how to serialize a custom color space to the Academy/ASC Common LUT Format using OCIO. Nick, how were you thinking of representing a custom color space in a USD document?
    • Nick: Pretty much like what you're showing with the CLF example. Although it would not have bit-depth attributes. Doug: Yes, that's an aspect of CLF that isn't relevant in this context and I would not propose including it in the data model, just assume it's always 32f.
    • Doug: So something like this would become a USD Schema?  Nick: Yes, exactly.
    • Nick: What does the basicPassThrough attribute mean?  Doug: That refers to how negative values are handled through the power function, OCIO provides four different options, such as pass through, clamp, and mirror.
    • Nick: Because nanoColor would be in the middle of the render pipeline, we're assuming that clamping behaviors have been resolved before it gets into the pipeline. The reason for that is that you might have an intermediate result that is out of gamut, but the the time you finish with the math it's back in gamut. So it would be introducing artifacts to clamp an intermediate result. Maybe it's better to say interpolation/extrapolation rather than clamping.
    • Doug: What if the rendering space is linear Rec.709 and someone brings in a texture that is in AP1. The conversion into the rendering space could map some positive values to negative values. Are you saying there's no desire for the color management to try and limit those?
    • Nick: It would be the responsibility of the person creating the assets to have thought that through ahead of time. If you get all the way to the BSDF with negative values, that's the point where you have to reconcile what the BSDF should actually do, if it should be creating out of gamut values. Another way to put it is that, it's fine if there is color management upstream that deals with that, but by the time it hits the shade graph, that has been resolved.
    • Doug: At a previous meeting we were discussing the diagram that shows the three groups of transforms. There are some, like Lut3D that are definitely not part of nanoColor, and others such as Matrix and Exponent that definitely are, but the ones we need to discuss are the ones in the middle that are needed for some of the OCIO-light use-cases such as color managing a viewport.
    • Nick: Yes, I think the dashed line in the diagram is not really nanoColor, it's the rendering color space boundary. So the question is whether any of those middle transforms belong one layer deeper, and at first blush, maybe the answer is no.
    • Doug: So those middle transforms would be part of nanoColor and they could be used in the built-in configs, but perhaps they won't be allowed for custom color spaces? Does that align with how you're thinking of them? Nick: Yes.
    • Doug: Maybe I should put together a document that describes the color space data model like that and give an example of how to use the OCIO API to serialize those values. Does that make sense?  Nick: I think so, yes.
  • Nick's Prototype Updates
    • Nick: I've boiled down the prototype to just the essentials. There were some extra things in there for testing such as calculating where the spectral locus is, but those are out of scope for what the library should have.
  • Color Space Naming
    • Doug: Since we have a lot of the people from the Color Interop Forum in this meeting, I'm wondering if we could try to make some more progress on the question of how to distinguish between the scene-referred and display-referred versions of sRGB. At the Forum meeting, Mark Boorer has suggested adding a "display" prefix rather than having a "texture" suffix. Thomas and I have been posting in a long Issue on the Color Interop Forum GitHub on this topic.
    • Nick: It seems it went from a little list to a big matrix of possibilities. How will it be resolved?
    • Doug: There are two questions: what is the list of color spaces, and then what is the compact name string for each of them that would appear in USD or MaterialX files. The group has about 3-4 spaces they want to add to the MaterialX list and we may be able to remove 1-2. So we're still only talking about 15 or so color spaces. The bigger topic of disagreement is what the name string should be.
    • Anders: I'm trying to think through what we do with the display prefix in the context of a USD Shade network.
    • Doug: Yes, I should clarify that the display-referred version would not be in the list of core texture asset color spaces. The issue is that we plan to follow up that list with a bigger list that we think is needed by other projects such as OpenFX and OpenTimelineIO that would include things like video color spaces. So we're trying to think ahead about what the overall naming scheme would look like, so we don't paint ourselves into a corner.
    • Doug: The reason that OCIO started appending "_texture" to sRGB was because, if you look at the spec, it's a display-referred color space. So we felt that if it's being used for textures as a scene-referred space, it needs something added to the name to indicate that. But I know people find that confusing.
    • Doug: The reason we have two color spaces in OCIO is so that applications know what kind of transform to apply to convert. If you're converting to a rendering space and you're starting with the scene-referred one, then it's just the gamma and the matrix. But if it's the display-referred one, then there's a view transform that needs to be removed. A practical example for the latter case is in advertising. Let's say someone has a product box and the logo needs to be a precise color on output, the texture map needs to go backwards through the tone-map to find out what scene-referred value will produce that color.
    • Anders: I certainly feel the best solution is to leave the scene-referred names alone and just add "display" to the other ones when necessary.
    • Doug: I think most of the people here share that view. My concern is that we've had mostly rendering people participating in these discussions so far, we haven't had video people and etc., so I've been trying to advocate based on what I think they would say.
    • Cuneyt: With the display-referred one, you don't know what view transform was used.
    • Thomas: That was my point as well. You know it's display, but then you can't do anything with it. That's why I'm saying it's not useful.
    • Anders: I know what you mean. But there might be some utility in it, for example, downloading an image from the internet, or conjuring something in Midjourney. Maybe you want to tag the image file as saying there's something funky here, but I don't know exactly what it is.
    • Doug: In OCIO there are basically two transforms for conversion: ColorSpaceTransform and DisplayViewTransform, so the display affix is telling the application to use the DisplayViewTransform (if converting to a rendering space). At that point the application knows if it needs to ask the user for which view transform to use. And even if you did know what view transform was originally used to create the image, you still may want to ask that, since maybe the same one is not appropriate.
    • Anders: I like the idea of having the affix on the display-referred side, so the details could be deferred, we don't have to bake anything in now.
    • Thomas: I'm not opposed to adding something, but it's frustrating not having the specific view transform. It's been a good conversation. Anders: Yeah.


  • No labels