Attendance:

Others:

• Li Ji

• Omprakash Dhyade

• Michael B. Johnson

Discussion:

• DWA compression

  • In 3.1, we switched from passing a named attribute to specify the DWA compression level to an argument to a method on the header object, and the result is that the file no longer stores what compression level was used. Was taken out of the header.

  • If you use the header technique, write the file and then read, there’s no way to know what compression level it was written at.

  • Should we have a convention to store the compression level.

  • Larry: I know you shouldn’t read lossy and write lossy, but it should still work.

  • Peter: Added the ability to do that for Zip. Got added to DWW at the same time. For zip, it doesn't matter

  • Used to be when the attribute was there, you could assume.

  • Kimball: a proposal came in, I made it so it worked.

  • The argument was to avoid a bunch of attributes that control how the file is written.

  • Any other compression like zstd, we should put the compression level in the data, not in an attribute.

  • Kimball: THe attribute should be a global default. If you use the attribute, it should use that regardless of what else you do.

  • Kimball: We don’t have a test to validate the metadata.

• Imath: operator[] for vector, box.

  • Taking the address of the x field is undefined behavior.

  • Larry: Intel compiler happily puts garbage values wherever you’ve defined.

  • KT: That’s why I added the struct with union.

  • OSL PR from Chris Kulla: Alex Wells suggests alternate implementation

  • Failing CI on Intel compiler.

  • https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/1865

• In the absence of being able to have less than 32 bit integers. 

  • Larry: If you use fewer bits, it compresses well, but there’s no way to tell when you read what the intention was.

  • Peter: There are unused bits in the channel descriptor.

  • Peter: The complexity of adding a new data storage type is big, it’s not tested for.

  • Application code has assumptions there are only three types. If half, else if float, else int32. Any solution would need to state “I support new exr types”

  • Could support significant bits at the FrameBuffer. Just uncompress the data into a buffer of the appropriate size.

  • This would mean we don’t ever need to add support for 8 or 16 bit integers

• Huf/Piz compression regression

  • Omprakash: Found performance regression with recent release.

  • 8K half float data, piz compression. 2x regression.

  • For ARM, specific to Apple.

  • Problem is in #defines fasthuf compiler options

  • Even with a fix, it’s still slower. 

  • Kimball: Previous code was copying std::map a lot