Attending:

Cary Phillips
Joseph Goldstone
Kimball Thurston
Larry Gritz
Nick Porcino
Owen Thompson
Peter Hillman
Rod Bogart

Discussion:

Larry: The 3.0 porting guide will probably be couple of pages, as a separate doc. Haven't gotten to it yet.
Kimball's new C Core:
- The C level is just about file IO. The goals is performance, memory optimization, and thread safety.
- We really won’t want to change the structure of the fie.
- The PR includes code a "namespace" mechanism via macros that make function and type names configurable at compile time. Is this useful?
  - Similar in spirit to the jpeg library: can configure the jpeg library as either 8bit or 12 bit; it swaps out the function names so you can have both in the same namespace.
  - Kimball: we might have an application for this mechanism at Weta, not really sure.
  - Code readability overhead seems high. Is it worth it?
  - If we're ever going to add it, now is the time. Easiest to put it in at the beginning.
  - Cary: Our mission statement says to place a high value on simplicity, reliability, maintainability, compatibility.
  - Cary: We should include this only if someone has an actual use case. Otherwise, it's unnecessary complication with no demonstrated benefit.
  - After discussion, Kimball will rip out the macro namespace thing.
- Next step is to replace the guts of the C++ library with the C library. Under the covers the gues will get swapped out, but the external C++ class API should not change.
- Kimball: The C layer is far more strict about types. If it encounters garbage data it rejects the file.
What is the timeline for the 3.0 release?
- Cary: There is obviously a lot more work to do to even get to a compilable, working version, much less a thoroughly tested, releaseable version.
- Rod: The VFX reference platform says 3.0.
- Could there be a build-time switch between new and old? Seems complicated.
- Alternatively, we could release more or less as is with the new C core there but not yet integrated into the C++ API. This would give access to the new code without any potentially destabilizing changes.
- Kimball: The biggest hindrance is the threading part of the library. I hate that OpenEXR creates threads. To get the maximum performance you’ll want to use the C layer. We lack a C++ layer that makes calls threadsafe.
- After discussion, we agree:
  - The 3.0 release will include the code reorg and bug fixes, but without the new C core.
  - Soon after the 3.0 release, we'll release 3.1 that includes the new C core as a side library. This gives access to the high performance, thread-safe file IO without altering the existing code or API. Users can access it if they want.
  - Over subsequent 3.2, 3.3, etc releases we'll migrate the C++ api to use the new core. This is possible because the API won't change.
Joseph’s Standard Optional Attributes should go into 3.0.
- Joseph: I have a PR almost ready. Haven’t filled out the CLA yet.
- Need to make sure there’s no existential conflict between up-vector and world transforms in the current implementation. Both imply things about where the camera is in relation to objects.
Report from the TAC meeting on proposal for new rawtoacess project.
- Kimball: Alex Forsythe at the Academy and I have been doing something similar. Would like to find a better home for the project.
- Propose rawtoaces - a project that merges existing versions of code into a common library.
Request from gregcotton for a point release that includes PR #854, fix to config for macOS. Should we include other bug fixes? Where do we draw the line? With 3.0 now likely in January, is that an acceptable fix? Cary will look at what other PR's might reasonably go into a 2.5.4 release.

Browser not supported