Attendance:

Guests:

• Vlad Lazar, Industrial Light & Magic

• Pierre-Anthony Lemieux, Sandflow Consulting

• Michael Smith, Intel / Wavelet Consulting

• George Tattersall

• Li Ji, Industrial Light & Magic

Discussion:

Quick Recap

The team discussed symbol versioning issues and prototype testing for different linker flags, with a new release requiring coordination between their team and Foundry. They explored handling security advisories and CVEs through formal processes, while also reviewing a PR for vending OpenJPH and discussing patch update compatibility. The group examined lossy compression methods for OpenEXR files, including potential quality trade-offs and compression ratio considerations, while also addressing gamma nonlinearity and value preservation concerns.

Next Steps

• Vlad: Create a temporary hack to unstick himself short-term while waiting for long-term solution

• Christina: Create a GitHub issue about the symbol versioning/linking problem to continue conversation offline and involve Vlad

• Cary: Post on Slack to direct people to check the GitHub issue if they have opinions on the linking/symbol versioning topic

• Cary: Submit update to OSS Fuzz to update OpenJPH every time it builds

• Cary: Do experiment to test if running test programs with LD path set to new shared objects works for the OpenJPH vending PR

• Cary: Add thorough summary in release notes for the DWA table optimization changes

• Pierre-Anthony: Consider creating a branch against OpenEXR library for the lossy compression work when the time is right

• Pierre-Anthony: Expand demo app to support tiles in addition to scanlines

• Pierre-Anthony: Implement decoder to only read the part of the chunk that contains specific resolutions

• Team/Community: Test Pierre-Anthony's lossy compression with various images and workflows to provide feedback on quality versus bit savings

• Team/Community: Test lossy compression on non-visual images like normal maps and depth maps to evaluate quality

Summary

Symbol Versioning Progress Update:Vlad reported making progress on understanding the symbol versioning issue and created a prototype to test different linker flags. Peter and Vlad discussed that a new release would be needed, not just from their team but also from the Foundry, indicating a significant timeline for a solution.

Security Advisory and CVE Management:Cary discussed the process of handling security advisories and CVEs, noting that it's better to go through the formal process of requesting them. Peter mentioned receiving a message from someone involved in building OpenXR, whom he had interacted with before. Cary also mentioned a private email exchange with the Zero Day Initiative regarding requested CVEs, which haven't been filled out yet. Larry reviewed a PR for vending OpenJPH, which turned out to be less complicated than initially thought, and confirmed that no OpenJPH symbols leaked out.

Patch Update Compatibility Discussion:Cary and Larry discussed the compatibility and release process of a patch update, agreeing that it should not require a minor version release as it involves hiding symbols and does not change the ABI. Peter raised concerns about potential issues with library linking, but Cary suggested testing with representative test programs to ensure compatibility. Cary also mentioned the need to update the fuzz test to automatically fetch and commit changes from the OpenJPH master branch.

OpenEXR Bug Fix Discussion:Peter and Cary discussed the bug fix process for OpenGPH and OpenEXR, with Cary explaining that the vending solution would be updated to verify fixes. Vlad presented a toy example demonstrating the use of different OpenEXR versions in the same executable, highlighting the need for symbol versioning and a custom namespace for OpenEXR core to avoid symbol clashes.

OpenEXR Symbol Versioning Discussion:The team discussed symbol versioning for OpenEXR core libraries, with Peter explaining that they currently use symbol versioning to tag the official version and maintain AVI compatibility. Vlad raised concerns about Nuke picking up incorrect symbols, particularly in Nuke 17, and the team explored how to ensure proper versioning and linking between C++ and C libraries. Kimball suggested a potential solution, and while Christina had questions about how symbol versioning could maintain ABI compatibility, Peter explained that it works by rejecting unversioned symbols. The team agreed that symbol versioning could be added in a future release without breaking compatibility, and Christina suggested creating a GitHub issue to continue the discussion offline.

GitHub Issue and Compression Discussion:The team discussed creating a GitHub issue to gather opinions on a technical matter, with Cary and Christina agreeing that GitHub would provide a more permanent and accessible record. Pierre-Anthony presented his work on a lossy compression app using the OpenEXR API, which currently uses 256-line chunks and supports 32-bit float data. The team explored the potential for adding features like channel decorrelation, with Peter suggesting that such changes might affect file compatibility. Michael and Pierre-Anthony discussed the need for user feedback on the quality versus file size tradeoff of the new compression method. Larry mentioned a surprising observation about DWA compression artifacts when viewing HDR images on non-HDR monitors.

OpenEXR Gamma Nonlinearity Discussion:The team discussed issues with gamma nonlinearity and lossy compression in OpenEXR images, particularly concerning values greater than one. Larry noted that while the visual differences were small, there were significant value discrepancies in the data that could be problematic for certain applications. Pierre-Anthony suggested examining specific test images to better understand the impact of these issues, though Larry clarified he did not observe any problems on HDR displays himself. The group acknowledged that OpenEXR is primarily a data format for intermediate steps, and any lossy compression could affect subsequent processing stages.

Lossy Image Compression Value Preservation:The group discussed methods for detecting and preserving values around 0 and 1 in lossy image compression, with Michael suggesting the use of an ACES viewing transform and Peter proposing the consideration of the PQ curve for perceptual quantization. They explored the possibility of encoder optimization to better preserve these critical values, as well as the need for a decoder to undo any preprocessing steps. Pierre-Anthony emphasized the importance of having experts review the compressed images to ensure they meet visual expectations, suggesting that now is an opportune time to address any issues found.

Lossy Compression for EXR Files:The team discussed lossy compression for EXR files, with Pierre-Anthony suggesting a 10:1 compression ratio as a good starting point, though they noted potential quality trade-offs. They explored the possibility of applying lossy compression to non-visual data like normals and alpha channels, with Michael suggesting smaller quantization steps could be used. The group also discussed DWA compression level settings, with Peter and Cary noting they had previously tested and chosen a high-quality setting that wasn't lossless. Finally, Peter explained the memory allocation behavior of an optimization for ERIS's table, clarifying that while the binary doesn't contain the table data, memory is allocated upfront to ensure thread safety.