Attendance:

Guests:

Discussion:

• Doug Walker: Question about how to make OCIO & OpenEXR work together, possibly recommend some best practices.

• OpenEXR & OCIO are both ubiquitous projects that do color management in incompatible ways:

•  

  • OpenEXR: chromaticities attribute, dates back to Florian at ILM. Not widely used in my experience. Augmented by putting color space names in the header, but there’s no standard.

  • OCIO: Color space name string, meaningful to a specific config file. A point of fragility in the current system. Color space do not have chromaticity data (community has resisted adding this). Historically, no way to bridge out from a given config to a known color spaces. OCIO v2 introduced a way to do this but it’s optional and relies on the config author to opt in.  Some people put color space name in the filename and path. OCIO does not know how to parse image file format headers to extract metadata.

  • OCIO v1: Path contains the color space name, otherwise default

  • OCIO v2: You can define a set of rules and regular expressions patterns and match to a color space.

  • SMPTE 2065-4 came out of ACES project, standardizes all of OpenEXR (at the time) except for the compression options. Introduces acesImageContainerFlag, set if the file contains SMPTE 2065-1 color space values.

  • ACES 1.3 ACES Metadata File (AMF), XML sidecar file, not widely used. Prototype provisional support recently added to OCIO via python.

  • And various proprietary/vender-specific color space names strings that get put in exr files today. OCIO tool ocioconvert when it writes images using OIIO sets color space to OCIO color space string. Weta,Flame, Baselight, After Effects have custom attributes.

  • Joseph: Everything is about identifying the content

  • Kimball: Florian’s original CTL, is it still in use? Another historical artifact, Florian’s idea of doing true color description in OpenEXR. Largely fallen by the wayside as being too hard. There were attribute names that describe the CTL files for the look transform. I mention it for historical reference.

  • Joseph: But that describes what would be done to the file. Everything Doug is saying is about describing the content of the file.

• Doug: I’m proposing in line with what proposed in the original email thread that we document standard attributes names to be used in the exr header.  Both the ocioColorSpace name and the ocioConfig name. In materialX, there are three attributes: colorspace config, and color management system. Makes it generic in terms of color management system. 

• My proposal: make the attribute color management system-specific. I don’t have strong feelings about these particular names, just a strawman proposal.

• Part 2 of the proposal is to add functions to OCIO to allow some chromaticity-based interoperability.

• Using OpenEXR Chromaticities in OCIO apps. Leverage OCIO v2 “aces_interchange role”. If present, it identifies ACES 2065-1 in that config. But it’s optional. Otherwise, use other heuristics to try to identify a known linear color space in the config.  It would use the chromaticities to build matrices from the OpenEXR colorspace to ACES 2065-1 using both Bradford and Cat03 adaptation.

• New functions to add:

•  

  • getColor SpaceFromChromaticity -> throws if not found

  • buildCOlroSpaceFromChromaticities -> throws if config cannot be reverse engineered

• Best practices proposals: Assigning OCIO colorspace to an OpenEXR file

  • If ocioColorSpace is present, check if it’s valid

  • If product-specific metadata is present, check if it’s valid

  • If acesImageContainerFlag is  present, ask OCIO for ACES 2065-1 color space

  • If chromaticities are present call getColorSpaceFromChromaticities

  • Else call buildColorSpaceNameFromChromaticies

•  

  • Take color space from external source (pipeline db, AMF file, MatX file)

  • Examine the openexr metadata (if feasible and desired)

  • Use OCIO file rules

  • Color space applies to all *.R, *.G, *.B channels in the file

• Kimball: A point of conflict, the chromaticities attributes are standard, meant to be in the base header. Should we deprecate it from the exr API? Favor sorting in Doug’s order?

• Larry: I’ve never seen chromaticities used in the wild. 

• Kimball: If they’re there, half of them are set incorrectly. Should we lessen their usage in the API?

• Peter: the opposite approach is to make them more significant. Then they become more important so people have to get them right or the pipeline stops working. Nice thing about chromaticities is they work across configs. If you get them right, you have a portable file.  Do we add getChromaticesFromColorSpace, so you can put them in the file correctly?

• Doug: That’s my question, do we need best practices for writing exr files? 

• How much emphasis do we want to put on chromaticities going forward?

• Larry: Different configs at different facilities can have completely arbitrary names

• Carol: we’re ignoring all the bad things people do. If you follow these rules we assume you’re writing a linearly encoded file.  

• Larry: Now we regularly ingest assets from other facilities, often with inadequate documentation or conflicting information about what color spaces they are. Facility to facility interchange would be nice.  

• Peter: And non-facilities. If a camera is creating exrs natively, does the manufacturer have to ship an OCIO config so you know what the color space is.

• Joseph: For the Alexa and the Amira, chromaticities were always written correctly. If tool writers use the toolkit we gave them, it was correct, but often it wasn’t used.

• Kimball: They took the exr file, loaded into somewhere else, and that torched everything. 

• Larry: That’s the more reasonable confusion. Nothing that comes from the camera survives very long. It goes through some ingest and conformance process that is probably something that’s converting it to internal conventions, writing it back out. In that process, all it has to do is lose some of those non-standard attributes, then suddenly you’ve got these bad files.

• Joseph: The supreme attribute for an openexr file are identifiable because they are in ImfHeader.h and not ImfStandardAttributes.h. Chromaticities are in ImfStandardAttributes.h. I don’t know the extent to which Florian considered it required. It’s required to be ST 2065-4 compliance, but no one cared about that. The reference implementation of OpeNEXR has never had half the attributes in there. 

• Joseph: We all contributed to the document, but that happened when nobody was supporting OpenEXR. No one ever picked it up. No one has inculcated that chromaticies matter or that you should get them right or wipe them out if you know they are undefined. It’s an official mess.

• Doug: It’s a problem if you’re reading a file and writing a new file. You might not want to forward anything from the original file.

• Kimball: There’s nothing to stop you from writing non-linear files. 

• Peter: If you’re writing nonlinear files, don't write the chromaticities, just put OCIO color space. 

• Carol: That’s why I think the OCIO color space should be the first thing checked, because it’s possibly the most reliable and purposefully set.

• Kimball: It’s encouraging people to write non-linear files. 

• Larry: There's no way to say it’s not linear.

• Doug: Relevant new OCIO features:

  • Naje ut easier ti define attribute file-name-friendly color space strings

  • Requires an interchange role to be present in both configs

•  

  • New function to ask if a color space is linear (OCIO 2.2). Right now, there’s no way to know.

  • Alias attribute of color spaces (OCIO 2.0

  • Function for converting between two colors spaces in different configs

  • The OCIO library will have standard configs built in

  • Provides a way of robustly identifying common color spaces

• Joseph: You’re using the term “standard”. Do you mean “common”?

• Doug: “Standard” is the wrong word.

• Kimball: I’d hope there are flavors of ACES that are codified. So we don’t have to recreate them.

• Peter: The config name helps. 

• Carol: It only works if you’re using one of our published configs. The config name means less if you’re a studio using custom configs, then ship the file somewhere but don’t ship the config. 

• Peter: The double thing of the color space name and config name, and the chromaticities. If you see the color space name but don’t know the config, you fall back to the chromaticities. You can’t necessarily trust that the space is correct.

• Rod: mostly, exr’s don’t need to be converted. The reason we’re talking about exr needing ocio information, I’m not sure I understand what we’re trying to say. Are we saying, “This is what you should use to look at this?” or are we saying “This is what was used to cause the data to be in the file”?

• Carol: It’s what the data file is. Used as a source. Yes, the chromaticities are all that you need, but what we’re discussing is that isn’t working.

• Rod: configs are intentionally vague about the working space. And there’s no guarantee that the names mean anything.

• Carol: it’s less vague with OCIO v2

• Doug: Typically, an application has a working space. In maya, the user indicates the render space it’s using. ACESCg, Rec709, etc. Whenever we load a texture, we call OCIO to convert from whatever is in the file to that space. The reference space is an internal detail of the config.

• Rod: Until you try to join two configs. If you want to join two configs, you have to use python to do it.

• Doug: There’s a function all in OCIO, you give it two configs and two color spaces, OCIO builds a processor that converts from one to the other.

• Rod: But the user doesn’t do that. If they got two off the internet that they want to combine, the tool they have is a text editor.  It won’t work, but they can’t tell it won’t work. There’s not enough information in the config to know they’re not text-editor compatible.

• Carol: OCIO wasn’t designed to be edited in a text editor. That wasn’t the intent. It’s been an unfortunate consequence of not enough ways for users to create configs.

• Peter: The text editor doesn't actually make life easier.

• Rod: I’m not sure that I agree with that.

• Larry: Not intended to be edited in a text editor by a non-color scientist.

• Doug: It would be nice to have a tool to edit config, add colors apces. That’s on our mid-term radar. 

• Rod: we can’t count on Nuke, Maya, Unreal to be that tool to edit config.

• Doug: From an applications pov, there’d be a master config. 

• Kimball: What would happen if we instead of describing a OCIO color space, but rather here’s a chunk of text that OCIO could slurp in that’s a codification of the processors under the covers of that color space definition. Basically, the old CTL idea.

• Doug: You can do that today. You can build a processor and export it. 

• Kimball: But put that in the header, rather than the color space name.

• Rod: All we’re trying to label what an exr is, not what it becomes

• Kimball: How to unambiguously describe the color space

• Larry: If people are just looking at headers, and they see a blob of text, nobody will understand what it corresponds to.

• Joseph: My other concern, when facilities are interchanging files and the attribute name is set, how do you know the attribute name has the same definition in both places?

• Rod: Kimball is asking, is there a way to distill it into the data, rather than the name.

• Kimball: Are we going to accept that people are storing data that’s not linear in exr files?

• Larry: We live in a world where people are writing the wrong chromaticities and passing them on even though they’ve done a color space transformation but they didn’t know they were supposed to change those attributes. What happens on the receiving end?

• Peter: That’s why I recommend having just chromaticities. Because if it’s wrong the pipeline stops working.

• Larry: We have to clean up what apps do with chromaticities.

• Rod: What should Nuke do? It’s not obvious what Nuke should do when it writes out an exr.

• Carol: The first thing to decide for exr is what to support. Then you have to do the long slog of getting everyone else to follow in line.

• Rod: But we’re considering saying, “One more thing you should support is this color space thing”

• Joseph: Four data sources, with redundancies. If we go with “it’s the chromaticities stupid,” we have to get rid of Aces image container flag. Then adoptedNeutral has to go. Need to remove possibilities where the file can be self contradictory if we want chromaticities to be taken seriously.

• Rod: Joseph is saying we prevent it from ever being inconsistent. Aspirational at best, but let’s say we can pull that off. 

• Carol: We’re at a place now where OIIO and OCIO are way more adopted than when we had these discussions before. 

• Rod: Would some sort of survey of use cases help? What’s successful and what would have worked. Would be helpful. 

• Joseph: I’m afraid of shows pandering to the least competent facility. If we rely on vendor software changes, I could see how one facility dictates how the production goes.

• Rod: We have the opportunity to be the change we want to see. We can make some best practices. 

• Rod: question about allocations. Is it associated with a color space? 

• Doug: There’s an attribute in the color space called allocation. It’s an OCIO v1 thing, it’s not really necessary in v2. 

• Rod: If someone has an exr that is tagged with a color space, it won’t be hindered by 

• Kimball: Where is openexr used?  Lots of people say, “Ooh, look, floating point image data.”

• Joseph: That's where I’d expect to see non-linearity.

• Peter: If they’re in their own bubble, it shouldn’t concern anyone.

• Rod: There are more than one type of “linear”. Scene linear, display-referred linear.

• Joseph: You could do anything but gamma correction and then store that.

• Joseph: This is the first time I’ve heard an argument for an image state flag.

• Peter: If you pull a JPG off Flickr, it’s probably with display baked in, ready for the HDMI cable.

• Larry: The original suggestion was, can we add a tiny bit of complexity to exr, to reduce complexity elsewhere?

• Kimball: We need to cogitate on this a bit more.

• Larry: Both projects have new releases coming out.