Attendance:

• Cary Phillips
• Christina Tempelaar-Lietz
• John Mertic
• Joseph Goldstone
• Kimball Thurston
• Larry Gritz
• Nick Porcino
• Peter Hillman
• Rod Bogart

Discussion:

GPU Compression

• Rod: compression demo is a 2 step process, did step one got it working, now a question of how would you design this for real
• Peter: comes back to if you make changes to any header field, gets into a backwards compatibility issue.
• Rod: wrestled with assumption that to use scan line interface, there is a jump table to find the scan line. In the GPU deal, you want the whole block, not the scanline. So this would have to exist on top.
• Peter: compression type only works for tiles, then there is a header at the beginning of the tile, then there could be additional API to get only the part of the tile you want.
• Rod: Rus was dealing with issue that the large tiles are full, you want to account for that and only read the small amount
• Peter: there is a lot of calculation and compute. I want the tile, how big is this going to be.
• Rod: do all this with the C interface, Kimball wanted to identify what the C interface needs to fully support, still TBD
• Rod: Need to redo the prototype and then decide whether to get guidance from Kimball for how to expand the API to support
• Peter: some of the inefficiencies the demo addressed were things Kimball had addressed in the C interface.
•  Rod: demo needs to step back one level so it works across platforms, get rid of microsoft-specific parts
• Peter: unintended feature of the C++ API - if you invent a new compression type, the library will check if it recognizes the compression type. C API will give you the headers when it reads, the C++ API won’t even get that far. The advantage is if you are using a new compression type, we can change the header since it will only be read for this compression type.
• Rod: recalls Kimball saying there would be a version bump, question is how big a bump is it  - EXR 4? Or just a dot release.
• Peter: thinks we should call it EXR 4 if there is any way to write a file that cannot be read by EXR 3. Thinking from an artist point of view. The last compression type went into 2.1 but no one ever used 2.0. 
• Peter: can add metadata, ID manifest in new version.
• Rod: use Cryptomatte?
• Peter: we use deep IDs, have 3rd party renderers that use Cryptomatte then they are converted to deep IDs. Feels like the native way of doing things. 
• Rod: Unreal doesn’t use deep data but we do make Cryptomatte things.
• Peter: OpenEXRId (https://github.com/MercenariesEngineering/openexrid)  uses deep file format to store Cryptomatte-like IDs. So you don’t need to render depth information, just storing ID and coverage. Interesting alternative way of delivering the same product you get from Cryptomatte but using deep. File format doesn’t limit you to a fixed number of ids.
• Rod: start to see issues in skinny overlapping such as foliage because sometimes there are more samples per pixel than Cryptomatte is saying there should be.

Open Source Forums

• Peter: One more meeting before Talk submissions need to be finalized (due 12/21), so need to start a Slack thread to plan.

Repo issues

• Peter: Various cmake questions unanswered. Latest is an imath cmake question, issue #357. Need to do an audit of the open issues.
• Docs don’t build when theme not found, could our build be updated to not build the documentation in this case?
• 133 open issues on OpenEXR - we should organize them.
• Build issues on Windows are always common.