Attendance:

Guests:

• Li Ji, Industrial Light & Magic

• Carol Payne, ASWF OpenColorIO TSC co-chair

• Doug Walker, ASWF OpenColorIO TSC co-chair

• Pierre-Anthony Lemieux

• Michael Smith, Intel / Wavelet Consulting

Discussion:

Quick recap

The team discussed plans for the upcoming OpenEXR Virtual Town Hall and the need to finalize API and attribute storage changes by September to align with the VFX Reference Platform release. They explored various technical implementations related to color space attributes and interop IDs in OpenEXR and OpenColorIO, including discussions about standard attributes, backward compatibility, and potential breaking changes. The conversation ended with decisions about adding new features like a bytes attribute type and tiled image changes, while also addressing the need for documentation and community feedback on the proposed changes.

Next steps

• Cary to submit a draft PR for adding the color interop ID attribute to OpenEXR.

• Doug to finalize the name for the color interop ID attribute at the Color Interop Forum meeting on Monday.

• Doug to start writing the white paper recommendation for the color interop ID.

• Carol and Doug to confirm the final name for the color interop ID attribute within a day.

• Pierre-Anthony to file a separate issue for addressing the tile compression support in OpenEXR tests.

• Cary to merge the PR for the tiled image fix.

• Cary to discuss with Barnaby about adding a type string to the bytes attribute type in OpenEXR.

• Cary to start putting together a slide deck for the OpenEXR virtual town hall on August 6th.

• Anthony and Michael to prepare for their presentation at the OpenEXR virtual town hall.

Summary

OpenEXR Town Hall Planning Meeting

Cary and the team discussed the upcoming OpenEXR Virtual Town Hall scheduled for August 6th at 2 PM, with Cary planning to prepare a slide deck focusing on J2K, which will be passed off to Pierre-Anthony for further discussion. Cary noted that past town halls had modest attendance but were recorded for YouTube, and Larry emphasized the need to finalize the API and attribute storage for OpenEXR by September to align with the VFX Reference Platform release. Doug mentioned a pull request for OCIO 2.5, which is expected to be part of the end-of-September release, and Larry stressed the importance of having the new attributes and API changes ready for the OpenColorIO release.

OpenEXR Interop ID Attribute Discussion

The group discussed the implementation of an interop ID attribute in OpenEXR, with Doug highlighting the need to decide whether to add a string attribute or make changes to how color space is read and written from the header. Peter suggested adding the attribute to the standard attributes list, which Larry clarified would primarily reserve the attribute name for future use. Carol emphasized that OCIO has no immediate requirements for this feature, while Larry expressed the need for lead time to document and implement changes in OpenImageIO to support the new attribute in this year's release. The team agreed on the importance of aligning releases in the September to October timeframe.

OpenEXR Standard Attribute Discussion

The group discussed whether to introduce a new standard attribute for OpenEXR and OpenColorIO, with Cary suggesting waiting a year before making it a standard attribute to allow time for community feedback. Carol noted that this change would be a breaking change for OpenColorIO 2.5, but Doug clarified that it was not a strict breaking change for OpenEXR clients. The team agreed that the attribute should be treated as one attribute rather than two separate ones, following feedback from Peter and Larry. Larry emphasized the importance of maintaining back-compatibility, while Carol raised the potential benefits of convenience functions that accompany standard attributes.

OpenEXR Attribute Management Discussion

The group discussed attribute handling in OpenEXR files, focusing on how to manage changes to attribute names and types. Peter explained that while deprecated attributes would remain in the standard list, changing an attribute's type would require a new name. Larry raised concerns about applications writing new color space names that might become incompatible with future OpenEXR versions, but Peter noted that the library could handle such conversions. Cary emphasized taking a conservative approach and aligning with other projects, while Carol supported this but suggested further discussions could continue on the EXR side.

Color Space Attribute Implementation Discussion

Doug and Peter discussed the implications of adding a color space attribute to a header in alphabetical order, which would make files untrusted if using old libraries. Peter suggested this was more of a proposed solution to an uncertain problem, and they could address it later if needed. They agreed that convenience functions for setting and getting the color space as a normal string in the header would need to be marked as deprecated in the new approach, while still being included in the standard attributes file to guide users towards using API calls instead. Larry expressed uncertainty about the necessity of separate getters and setters for string attributes, but Peter confirmed that they are necessary for standard attributes.

EXR Color Space API Transition

Larry and Peter discussed the handling of color space attributes in EXR files when using a new library. Peter explained that files written with the old API would show the attribute as untrusted when read with the new API, but it would not be dropped. He suggested that the new API might be more trouble than it's worth. Carol noted that they have been living with the current ambiguity for some time and any improvements would be welcome, though the transition would be challenging. They discussed the possibility of adding functionality to check config files and warn users about potential issues during the transition.

Color Interop ID Standardization

The group discussed the implementation of color interop IDs in OpenEXR and other related software. They agreed to add a color interop ID attribute as a standard in OpenEXR, while OpenColorIO will add an interop ID on their side. Larry expressed his desire to simplify OpenImageIO's color space handling in the next release, relying on the new conventions set by the Color Interop Forum. The team also discussed the need to publish a white paper on the Color and Display Forum to explain best practices for using the new attributes.

Color Space Feature Implementation Plan

The team discussed implementing a new feature related to color space/interop ID. Cary and Peter agreed to proceed with adding a single line of code and related comments, pending finalization of the name, which Doug and Carol will address at an upcoming meeting. Carol suggested having a draft ready before SIGGRAPH, with a week allocated for feedback. The team also addressed a separate issue regarding tiled images, with Pierre explaining the changes and Cary recommending improvements to the test suite. Cary agreed to merge the tiled image changes and file an issue for additional test improvements.

Bytes Attribute Type Discussion

Cary and Peter discussed the addition of a bytes attribute type with an optional subtype string. Peter argued that having a type string would provide flexibility and safety, while Cary expressed concerns about potential misinterpretation of data types. They agreed that while the type string is not mandatory, it could be useful for validation purposes. Cary planned to discuss this further with Barnaby to see if he would be willing to use the new feature.

Christina’s Notes:

• Color interop forum

  • Cary: will support but not driving it

  • Doug: virtual town hall, not clear what we will be sharing

  • Michael: maybe not a time pressure for this

  • Larry: it is urgent since all 3 projects have September-ish releases?

  • Cary: but if we do it in October, no one will use it until the next year. Want to make sure not to miss that cutoff.

  • Doug: on OpenEXR side, not clear whether there is API change necessary. discussed suggestion we would change the way color is read and written from the header, per Peter’s suggestion.

  • Cary: amounts to adding to a list of standard attributes rather than being elective.

  • Doug: always written? required?

  • Peter: just means there are convenience functions to attribute. Standard list is attributes that should be there.

  • Carol: from OCIO side, fine with whatever decided. No requirement to have it happen in OpenEXR. We just need to be able to write the attribute. Just need to know for the sake of planning presentations.

  • Larry: would like the mechanism there but need lead time, have to document it.

  • Cary: given where we are now, should we just leave OpenEXR as is, let OCIO set it as an extra piece of metadata, wait a year, make sure settled on good solution.

  • Carol: could be fine but would be breaking change.

  • Doug: doesn’t have to be adopted right away but we are setting it in stone. 1 vs 2 attributes question… settled on 1 called “interop ID”.

  • Larry: concerned about ensuring that applications which start writing new color space names into OpenEXR files now should still be able to read that color space information a year later when OpenEXR catches up with implementation. Want to avoid situation where files become unreadable for color space information retroactively.

  • Carol: presents a clear picture for everyone if it is already in the header. Though the conservatism is understandable.

  • Doug: it might not be as trusted if it is not officially in the header definition.

  • Peter: whenever use old library to read in and out, you run into the situation of losing the information. There is a way to take steps to ensure that it is correct. But could be done later on. Would have to switch to the API to get trusted status later on.

  • Doug: to get and set colorspace would not treat it as a normal header attribute.

  • Peter: there are already a has/get/set for attributes, Joseph added them, all float.

  • Peter: old API would be marked as untrusted. if you write a file using the old way of doing things, it would not be written out. Can read in the old file but can’t write out the new file without the new API. API may be more trouble than its worth. Trying to address problem of what’s to stop someone from writing out the old attribute.

  • Carol: we have been living with this ambiguity so any steps toward fixing that will be good.

  • Peter: don’t need new OCIO to write the correct attribute? Just need to do it yourself and know what the right name is.

  • Doug: originally were going to color it “OCIO color space” but should name it “OCIO interop something”.

  • Carol: “color interop ID” so “color” is still in the name. Technically not describing an OCIO color space anymore.

  • Doug: a lot of studios have their own color ids already anyhow. All in agreement that basic outline is:

    • add the interop ID on OCIO side,

    • publish a white paper on best practice,

    • on OpenEXR side add color interop ID as a standard,

    • on OpenImageIO side Larry make sure it is copied into that metadata structure.

  • Larry: want to start making sure the files can be written/read and all plumbing in between can cue off it when needed.

  • Cary: think we should move forward with this change.

  • Larry: need a final name.

  • Cary: we should submit a PR with the final name that Carol & Doug agree on. Maybe PR should come from OCIO?

  • Doug: color interop forum meeting on Monday, want to finalize the name at that meeting. Will try to start writing the white paper / recommendation.

  • Cary: Changes in one header and cpp file. Any analog in the core library?

  • Peter: don’t think so. Comment can mention this is reserved for future use.

  • Carol: want to talk about this recommendation at SIGGRAPH. Have a period to modify it if needed.

  • Cary: submit PR have public discussion about it.

• HTJ2K PR

  • https://github.com/AcademySoftwareFoundation/openexr/pull/2072

  • Cary: that’s a trivial change, will merge after the meeting.

  • Pierre: tiles as small as 1x1 are permitted, tested as part of the unit test. Existing code assumed there would be at least a few bytes. Caught by the CI.

• Bytes attribute type PR - Barnaby Robson

  • https://github.com/AcademySoftwareFoundation/openexr/pull/2074

  • Cary: hasn’t problem always existed, that another part of pipeline is going to see attribute, think it means one thing when it is another. Same could be true of a string attribute

  • Peter: anything that is a string will be displayed as a string, but with a byte doesn’t know what to do with it. Counterargument is that EXR has typed attribute but this kind of subverting that as an untyped attribute. There is no undocumented “bunch of bytes” type.

  • Michael : J2K has a binary type.

  • Peter: not an issue with adding a descriptor. What you don’t want it an app that assumes every byte attribute is pickled Python and execute arbitrary code through unpickling.

  • Cary: basically saying, stick those attributes off to the side.

  • Peter: readers could iterate over byte attributes, check the string type descriptor, and parse accordingly if they recognize the string type.

  • Cary: question of adding a piece of extra information. What we may find in the wild is that people may not understand what to do here. Readers are not going to know how to interpret that value or whether it can be trusted. Purports to add some level of assurance.

  • Cary: no requirement that it actually be used…

  • Peter: seems overly limiting to require it, wastes a byte to say the sub-type string is empty.

  • Cary: will discuss with Barnaby.