Attendance:

Guests:

• Li Ji, Industrial Light & Magic

• Pierre-Anthony Lemieux, Sandflow Consulting LLC

• Dan Caffrey

• George Tattersall

• Mark Leone, Nvidia

• Michael Smith, Intel / Wavelet Consulting

Discussion:

Quick Recap

The team discussed recent bug reports and security issues related to OSS fuzz, with Cary confirming most issues had been resolved except for two in OpenJPH. They reviewed various test case fixes and PRs, particularly regarding OpenEXR changes and ZDI email issues that required Kimball's review. The conversation ended with extensive discussions about GPU decompression implementations, lossy compression algorithms, and potential API modifications for OpenEXR, including exploration of new compression methods and progressive decoding capabilities.

Next Steps

• Cary: Stage release candidate this afternoon and make a new release

• Cary: Merge the PRs that Kimball approved

• Cary: Figure out how to add Anous to confidential issue pages

• Cary: Report issue with 4 test cases as completed

• Peter: Confirm if fix resolves all test cases

• Mark: Continue working on GDeflate benchmark to demonstrate performance improvements

• Mark: Retry rebasing NVIDIA's fork atop current Libdeflate master using a different AI model

• Mark: Reach out to Libdeflate maintainer to see if they can rebase NVIDIA's fork

• Mark: Address comments about Basel build in the pull request

• Mark: Analyze scanline size performance with different chunk sizes for GDeflate

• Mark: Pursue Microsoft Direct Storage path for GPU Direct Memory Access

• Pierre-Anthony: Work on proposal for JPEG meeting in Sydney in January regarding floating point improvements

• Pierre-Anthony: Experiment with custom pipeline for resolution progressive decoding using J2K

• Pierre-Anthony: Test with very large images and evaluate lossy compression with tiles

• George: Provide sample images to Pierre-Anthony for testing

• Pierre-Anthony and team: Get answers on preserving infinities and NANs for lossy compression

• Kimball: Provide context/code for decoding pipeline to Pierre-Anthony

Summary

OSS Fuzz Bug Report Discussion:Cary, Peter, and George discussed the recent flurry of bug reports and security issues, potentially linked to a new version of OSS fuzz. Peter suggested that the OSS fuzz stops fuzzing when it finds a bug, leading to a continuous stream of issues. Cary mentioned that all OSS fuzz issues have been resolved, except for two in OpenJPH, which Anous has been addressing. Cary also expressed difficulty in adding another person to an issue page, which he is trying to resolve.

Test Case Resolution Status Update:Cary and Peter discussed the resolution of several test case issues, with Cary confirming that issues 0, 2, and 4 had been fixed and Peter agreeing that his fixes addressed all four cases. They noted that two PRs were needed to resolve the deep pointers path issue, one for the EXR check and one for the core library. Cary mentioned that Kimball needed to review certain PRs before they could be merged, particularly regarding a ZDI email issue that Kimball had marked as resolved but left a note about. The team agreed to wait for Kimball's input before fully concluding the resolution of these issues.

OpenEXR Development and GPU Updates:The team discussed several updates and issues related to OpenEXR. Cary mentioned that he would merge some changes and stage a release candidate later that day. Kimball and Peter reviewed some code changes, agreeing that while they weren't a complete solution, they were acceptable. Cary also addressed an issue with email notifications for bug reports, submitting a PR to remove http://OpenEXR.org as a notification email and list only specific team members instead. George from Foundry provided an update on their work with GPU decompression of EXRs, including their current B44 GPU decoder in production. Mark and Kimball discussed the progress of GDeflate and potential metrics, noting that while there's no lossy variation, there's a closed-source GPU implementation that's highly parallel.

GDeflate GPU Performance Analysis:Mark presented findings on GDeflate implementation, noting that while the GPU version is 2 years behind the Lib2Flake fork, CPU performance is already maxed out with 8 threads on NVMe drives. He demonstrated that batch processing of 50 tiles is necessary to achieve parity with CPU performance, and while GPU implementations show promise for large batch decompression of entire mipmap levels, the current implementation struggles to outperform CPU decompression due to NVMe throughput limitations. Mark also shared challenges with GPU Direct Storage under Linux, noting that while NVIDIA GPUs can perform DMA from NVMe drives, he has been unable to get it working on multiple machines despite trying different configurations.

OpenEXR Compression Implementation Discussion:Mark and Kimball discussed drive specifications in bits versus bytes, which could explain discrepancies in Mark's numbers. Mark mentioned he has a PR for OpenEXR using the CPU implementation and is not in a hurry to get it merged unless there's a compelling case for 5X faster decompression times than the GPU. Kimball inquired about the necessity of a separate compression type due to added metadata, and Mark confirmed it's a paged format with metadata written before compressed blocks. Kimball also plans to deprecate public compression classes in the C++ library, and Mark confirmed compatibility between CPU and GPU implementations for TX round trips. Larry inquired about the closed-source GPU implementation's licensing and usage, to which Mark confirmed it's free and supports GPU-accelerated compression for the EXR format. Cary asked about Mark's consideration of reaching out to Libdeflate maintainers for potential merging of changes, but Mark noted challenges with rebasing NVIDIA's fork atop the current Libdeflate master.

EXR Build and JPEG 2000 Encoding:Mark discussed ongoing issues with the EXR build against NVIDIA's fork and plans to reach out to the maintainer for rebasing. Kimball highlighted the contribution to Lib Deflate, allowing memory allocation control in EXR, which might have caused some of Mark's pain. Cary mentioned that there is no rush for the pull request to be accepted, and Mark agreed, stating that he is not in a rush either. Peter suggested analyzing the scanline interface size and potentially making it larger or offering two options. Pierre-Anthony provided an update on lossy JPEG 2000 encoding, discussing the need for full-frame encoding to avoid artifacts and the importance of covering 32-bit and 16-bit lossy requirements. The group also considered whether to preserve NaNs and infinities in lossy encoding.

Lossy Depth Map Compression Challenges:The team discussed the preservation of infinities in lossy image compression, particularly for depth maps. They explored the possibility of developing a lossy compression algorithm that maintains infinities, though Peter noted philosophical challenges with this approach. Kimball and Michael mentioned that depth maps typically use 32-bit floats, which can handle large numbers. The group also discussed OpenJPH's support for lossy flow compression and the potential for further improvements. George inquired about the timeline for proposing a new compression method for the January JPEG meeting in Sydney.

JPEG 2000 for Virtual Production:The group discussed modifying JPEG 2000 for virtual production needs, with Pierre-Anthony explaining that minor changes could be implemented in parallel with the ISO administrative process, potentially taking 18 months from initial ballot to publication. George shared that virtual production teams are seeking a new codec that offers better performance than NotchLC, with Netflix suggesting HTJ2K as a potential solution, and the team agreed to explore lossy EXR options. Pierre-Anthony requested sample images to better understand the requirements, while Peter suggested alerting users about potential tile artifacts when using single-tile compression, with George confirming that 16-20K resolution is common for virtual production needs.

OpenEXR API Feature Enhancements:The group discussed potential API changes and file format modifications for controlling channel correlations in OpenEXR, with Pierre-Anthony confirming these could be added to their list of features to target for year-end completion. George raised questions about the mapping of data windows and progressive resolution decoding between J2K and EXR formats, which Pierre-Anthony clarified remains unresolved as the current OpenEXR API doesn't fully exploit J2K's hierarchical framework. Kimball and Michael confirmed that while the current EXR API provides complete image data upon request, there's potential to add more advanced decoding capabilities through modifications to the OpenEXR API.

OpenEXR Progressive Decoding Implementation:The team discussed implementing progressive decoding and region of interest functionality in OpenEXR. Kimball explained that applications can replace the decoding pipeline by overriding specific function pointers, though he noted some incomplete aspects in his current implementation. Pierre-Anthony agreed to experiment with creating a custom pipeline, starting with resolution progressive decoding, and planned to test it with very large images up to 32K resolution. The discussion also covered the ability to decode only specific regions of an image, which Peter noted could help prevent crashes from reading overscan areas.