Attendance:

Others:

Discussion:

Quick Recap

The team discussed various technical issues and improvements, including array notation changes, bug fixes, and integration of new libraries. They addressed licensing concerns, pull request review processes, and release procedures, agreeing on version 3.4 for an upcoming release with new features. The meeting also covered documentation enhancements, with a focus on improving code examples and validation methods.

Next Steps

• Pierre-Anthony: Submit PR for the HTJ2K compressor Windows bug fix

• Larry: Review Pierre-Anthony's PR for the HTJ2K compressor Windows fix

• Kimball: Clean up and test OpenJPH optimization code with multiple compilers before contributing upstream

• Kimball: Submit an issue to OpenJPH about making memory allocation substitutable

• Kimball: Proceed with vendoring OpenJPH similar to what was done for deflate

• Peter: Learn the release process from Cary to serve as backup release manager

• Cary: Implement more frequent patch releases to address the release cadence concerns

• Cary: Change the example code in the documentation to use "row" and "column" instead of "x" and "y

Summary

Array Notation and Software Updates:The team discussed a pull request related to array notation, with Cary and Peter agreeing to change the use of x and y to row and column to align with standard conventions. They also touched on a recent announcement that Unreal is switching to a y-up orientation, which Kimball noted could be challenging for supporting different software systems in Manuka. The conversation briefly included Peter's mention of a new camera and some home renovation work involving a leaky ceiling.

Bug Fixes and Library Improvements:Pierre-Anthony reported a bug in the H.265 compressor on Windows related to the OpenGPH library, which has been fixed with a PR that also improves the code by removing real locks. Kimball noted that the J2K library breaks the OpenEXR core's memory allocation contract and plans to open an issue for OpenGPH to address this. Michael mentioned that the Windows implementation is now 10 times faster after the fix. Cary and Kimball discussed vendoring a subset of OpenJPH for use in their project, with Kimball planning to contribute upstream after cleaning up and testing with more compilers. Cary also informed the team about a fix for the Python wheel build failure on universal macOS, which was caused by incorrect handling of architecture-specific builds.

Cockadoo Integration Discussion:The team discussed integrating Cockadoo into their system, with Pierre-Anthony explaining that it could be done by using conditional compilation based on the presence of Cockadoo, similar to how OpenCV handles licensed libraries. Kimball confirmed this approach would be acceptable for their needs, and Pierre-Anthony indicated he would submit a pull request later in the week or early next week to implement this. Cary raised the question of whether Cockadoo would integrate directly with their bill system, to which Pierre-Anthony confirmed it would require minimal customization.

Kakadu and OpenEXR Licensing Discussion:The team discussed the licensing implications of including Kakadu code in OpenEXR, particularly regarding GPL compatibility. They agreed that while OpenEXR could be licensed under GPL, any Kakadu code compiled in would be subject to its commercial license conditions, requiring clear documentation of this limitation. Kimball suggested adding an API to register decompression pointers, while Peter proposed a runtime solution where the Kakadu driver could be installed separately from the OpenEXR core, with no direct mentions of Kakadu in the public API.

Pull Request Review Process Improvements:The team discussed pull request review processes and challenges. Cary and Larry shared their experiences with PRs sitting for extended periods without review, leading to Cary's current practice of merging unreviewed PRs after a week. Nick suggested implementing an open timeline system where PR authors can assign specific reviewers, which helps prioritize reviews. The team agreed that while the review process isn't perfect, Cary's current approach of giving adequate time for reviews before merging is better than immediately merging without review. Kimball noted that he reviews PRs during dedicated time blocks rather than relying on email notifications.

Automating Release Processes and Testing:The team discussed release processes and cadence, with Cary explaining his plan to automate and expedite patch releases for the low-traffic project. Cary agreed to train Peter on the release process, as he might need to take over some responsibilities. The group also addressed the timing of OSS fuzz fixes, with Kimball suggesting that automated patch releases could be triggered by PRs against the release branch. Peter proposed allowing OSS fuzz runs on the main branch for additional testing before pushing to release branches.

Version 3.4 Release Planning:The team discussed the versioning for a new release that will include HDJ 2K and a new compression type. They agreed it should be version 3.4, as it's a minor release with no API changes. Peter suggested adding version flags to the file format, but the team decided against it for this release. They also discussed including the Imath folder in the include path, and agreed to merge PR 1676 into the 3.4 release.

Enhancing README Code Example:The team discussed improving the support record code example on the README page and website. Cary proposed changing the example to create a rectangular image with horizontal stripes to better illustrate the concept of rows and columns. The team agreed that labeling the variables as rows and columns would be more intuitive for users. Cary planned to make this change to the code and documentation.

OpenJPH CI Build Improvements:Cary discussed a pull request that fixes CI build issues for OpenJPH by adding proper CMake dependencies and validation steps. The changes ensure consistent build behavior across Linux, macOS, and Windows, and validate both pre-installed and fetched library versions. Larry noted that while the OpenImageIO build system might skip OpenJPH checks when using external installations, Cary's PR provides a more thorough test. The discussion concluded with Pierre-Anthony suggesting that example code should be moved to unit tests for better code coverage and maintenance, though Larry and others agreed that maintaining a clear distinction between example code and unit tests is important.

Documentation Code Example Improvements:The team discussed documentation improvements, focusing on code examples and validation. Larry shared a solution where code fragments are tested within a complete C++ program, while Cary's approach only validates syntax without execution. Peter noted that the documentation lacks examples showing how to populate arrays in row-major order, suggesting the addition of a link to the source repository for complete code examples.

Edit