Attendance:

Guests:

• Pierre-Anthony Lemieux, Sandflow Consulting

• Michael Smith, Intel / Wavelet Consulting

• Li Ji, Industrial Light & Magic

Discussion:

Quick Recap

The team discussed updates to USD and OpenEXR, including changes to B44 log tables and table generation systems, while also addressing OpenJPH handling within OpenEXR builds. They explored various compatibility challenges between different EXR libraries and discussed the importance of maintaining standards in OpenEXR development. The group concluded by addressing specific technical issues with EXR image compilation and reading, particularly on Windows platforms.

Next Steps

• Nick to update USD to OpenEXR 3.4 with interned version.

• Nick to merge Eris's change to switch from B44 log tables to on-the-fly compute.

• Nick to run the B44 table changes against internal suites to check for any issues.

• Larry to address the OpenJPH installation issue to prevent it from leaking to the outside world when building OpenEXR internally.

• Peter to consider adding explicit messaging in CMake output about OpenJPH being built internally.

• Peter to consider adding explicit handling of compression code 99 to provide better error messages.

Summary

USD OpenEXR Update Discussion:The team discussed updating USD to OpenEXR 3.4 and debated a change to switch from B44 log tables to on-the-fly compute. Nick and Peter agreed to proceed with the simpler table lookup version, as it should be safe and provide a clear comparison with the old version. They also briefly considered a GPU implementation of B44 compression as a potential future project, noting its unusual nature and potential benefits for GPU decoding.

Table Generation System Changes:The team discussed changes to a table generation system, where Peter explained that while the tables were previously generated at compile time, they are now generated once and installed, similar to the historical approach. Nick confirmed that Eris's code uses bitwise checks and IMath functions which are well-defined and not subject to CPU differences, while Peter suggested adding a test to validate the table generation against the historical values. The team agreed to merge the changes and monitor for any issues, with Nick planning to run tests against their internal suites using B44.

OpenJPH Integration in OpenEXR Builds:Larry and Peter discussed the handling of OpenJPH within OpenEXR builds. They agreed that OpenJPH should not be copied into the OpenEXR installation when building from source, as this could lead to version conflicts. For package managers, they decided that OpenJPH should be treated as a separate dependent package. Peter suggested adding clear messaging in the CMake output and installation instructions on the website about the internal OpenJPH build. They also discussed the potential need to rebuild OpenEXR if there are security issues with OpenJPH.

IMath Versioning and OpenEXR Compatibility:Larry and Peter discussed the challenges with IMath versioning and its impact on OpenEXR API compatibility. They explored potential solutions, including using stripped-down classes for data layout or passing raw data types, to address the issue of ABI breaks. They also considered auditing where IMath is used in OpenEXR and discussed the possibility of disabling namespacing, but expressed concerns about adding more binary incompatibilities.

EXR Library Compatibility Discussion:The team discussed the challenges and compatibility issues between different EXR libraries, particularly OpenEXR and TinyEXR. Larry and Peter explored the limitations of reading and writing EXR files with different compression codecs, while LI mentioned TinyEXR's growing popularity and its use in the Godot game engine. Peter suggested handling unsupported codecs by explaining their nature rather than failing silently, and the group agreed that the official EXR library would recognize unsupported codecs but could provide more explicit error messages.

Godot's Role and Compression Standards:The group discussed the role of Godot as a significant player in the industry alongside Unity and Unreal. They debated the merits of adding new compression methods to standards, with Larry and Peter suggesting that using strings instead of enums could prevent arguments about random number selection. Michael proposed standardizing formats in organizations like Simpti, but Nick clarified that ACES already has a standardized format without compression. The conversation touched on the potential for OpenJPH to be referenced in other standards due to its use of JPEG 2000, and Larry explained that ACES originally omitted compression to avoid the complexity of writing specifications for multiple formats.

OpenEXR Standards Discussion:The group discussed the need for standards in OpenEXR, with Michael and Peter expressing that standards are most useful when they reflect what people want to do or are doing. Pierre-Anthony emphasized that specifications help reduce fragmentation across implementations by allowing clear expression of interoperability requirements, while Peter noted that standards might not prevent someone from adding new features. The discussion touched on the possibility of having a two-standard approach, with reserved values for future use, and the importance of maintaining OpenEXR's open nature, allowing users to compile and decode any data without additional licenses.

EXR Image Compilation and Reading Issues:The team discussed issues with EXR image compilation and reading, particularly on Windows. Nick explained that his Nano EXR implementation was a wrapper on top of C-Core for single compilation unit support, though some patches didn't get merged. Peter mentioned a recent issue where Tiny EXR was reading images upside down, which was traced back to a macOS preview bug related to line order. The team agreed to fix the Tiny EXR issue, and the conversation ended with participants moving to their next meetings.