Attendance:

Discussion:

• Doug: On the OCIO side, for 2.2 later this fall, some new features to help out with managing color spaces.

• Cary: What are the rules for forwarding metadata?

• Doug: On the OCIO, we could write a helper function.

• Peter: We’ll need to have a “name” attribute and chromaticities.

• Peter: Chromaticities are safer. It can be incorrect, but it can’t be ambiguous. But it’s hard to get right.

• Doug: in color science, there’s been a push to augment data, so it’s either scene-referred or display-referred. 

• Joseph: a color image encoding.

• Doug: Most of the time openexr are scene-referred.

• Joseph: if we are faced with applications that might change the color space. Exr in and exr out. But the application doesn’t support rewriting the chromaticities flag. If we provided the ability to update the data in place? 

• Peter: A standard tool to fix things would go a long way. How common is it that a tool reproduces all metadata? Most apps strip all of it out. Maybe the attribute copy could do in-place modification if possible.

• Joseph: We want to keep the momentum of the idea going, even if the application lags behind.

• Peter: We shouldn't give up on doing it right because it will take a long time.

• Peter: Foundry said The idea runs into problems quickly. They want to make sure Nuke doesn’t exacerbate it.  

• Doug: In nuke, there’s a tool for forward metadata, but it doesn’t support chromaticities. 

• Peter: If you have to do it manually you’re likely going to do it wrong.

• Doug: Flame has an environment called “batch”. Images have a colorspace attribute. If you have a comp node that blends two images, it deals with it.

• Joseph: You have to assume the user is doing something intentionally. 

• Doug: In flame, there’s a drop-down to indicate the output color space file. If you’re applying a LUT, there’s no way to know what it’s doing.

• Joseph: Do CLF files carry a color space?

• Doug: Yes, but there’s no guarantee that it matches a color space name.