Attendance:

Guests:

• Li Ji, ILM

Discussion:

General

• Li Ji - intro again, background in Windows, hopefully can help out with Windows related issues.

GDeflate

• Rod: work presented by Rus would be beneficial to have simple way to read a block of data, get bits out of the file and onto the GPU quickly, get us into state where GPU buffer is ready for regular use. Rus proved out that it is doable - now a question if it's possible for the compressor to be more general

• Cary: Kimball designed C core for this type of use case

• Rod: need to discuss with Kimball to determine how much work remains, who should do it

• Nick: made a small example that calls nanoexr, does rgb read/write - hoping to upload eventually. nanoexr + exrcore much tinier than tinyexr, would be good to have in our repo.

• Nick: Kimball added DWA compressor. We have DWA enumeration, treat consistently throughout, but difference in core implementation is the number of scanlines to be consumed at once. Is this correct?

• Peter: should work, my understanding is that is the only difference. Not sure why the number of scanlines is hardcoded.

• Rod: came up at Epic, we don't highlight which compressor types are entirely lossless, not part of their name or an attribute. Ran into situation where people were using a compression type for Cryptomat and ended up using a lossy compression but then all values were meaningless. No simple way to know to use the available lossless compression options.

• Peter: no artist friendly guide for OpenEXR

• Rod: the artists explicitly chose the compressor so if name had lossy in it, they may not have chosen it.

• Nick: this document does identify lossless vs lossy: https://openexr.com/en/latest/ReadingAndWritingImageFiles.html?highlight=dwa#compression

• Rod: reached out to Kimball to set up a discussion

• Peter: whether this compression can just be another compression type or does it need a new attribute as well.