TSC Meeting Notes 2021-09-23

Attendance:

Cary Phillips
Christina Tempelaar-Leitz
John Mertic
Joseph Goldstone
Kimball Thurston
Larry Gritz
Nick Porcino
Peter Hillman
Rod Bogart
Scott Wilson
Arkell Rasiah

Agenda:

  • Namespacing/API-compatibility

  • Rust bindings

  • 3.1.2 release

Discussion:

  • PR 1153, divide-by-zero with invalid chromaticities: 

  •  

    • Peter: should the library prevent bad chromaticities from being written? They’re just data. Not sure.

    • Larry: the modern way to divide floats is just to do it, then check if the result is invalid.

    • Peter: But the sanitizer used in the fuzz tests is triggered by the initial operation, so while that ensures proper behavior, the tests will still fail.

  • Arkell: gather reference footage?

  •  

    • Wanted to add some stuff from when I worked on RV. Had also gathered some data when at Pix.

    • Just “Representative images”

    • From Mank: Monochrome

    • We don’t cover wider gamut color spaces

    • Combos of display window, there were a few holes there.

    • Some data might be quite large. Do we want a few 8k images?

    • Will have some time in December/January

    • Will report back with a suggestion of what to gather. 

  • Joseph: 10 different groups are trying to standardize camera metadata. 

  •  

    • The “C” in “ACES” stands for “Color”, but nothing I was saying involved color.

    • Best thing we can do is come up with very precise definitions of things.

    • Example: the mark on the side of an ARRI camera is the focal plane? No, it’s the front of the sensor pad.

  • Scott Wilson - Rust bindings

  •  

    • We have a crate out

    • Getting ready to set up an announcement

    • Still need to set up CI

    • We can get people to start hacking on it.

    • Ready to hand off the openexr bindings

    • Kimball: What are the constraints in terms of ABI compatibility? When someone says import exr, does Rust have a strong opinion about versioning?

    • Scott: It all gets compiled into a static library. Every rust project defines cargo.tunnel, declaring what it expects. Then it resolves the packages. It assumes semver.

    • CI: get it out, for windows, mac, linux

    • ASWF docker container? I think so.

    • Separate repo that links to the main exr repo. Larry: What about keeping the two in sync, simultaneous PR.

    • No need for us to hand over the crate at this point.

  • Core library & error messages

  •  

    • Larry: 

    •  

      • starting to dive into the core library

      • Kimball submitted a PR to OIIO to make the OpenEXR reader depend on Core library.

      • Core library: reentrant so separate threads can read from the file.

      • Old OpenEXR: thread pool, do decompression simultaneously.

      • I refactored the reading

      • It’s at least as efficient as before, at least for image files.

      • For deep, about 2x, 3x for scanline deep.

      • The old library was pretty good at taking advantage of parallelism

      • Now, I’m rigging up texture system test

      • So far everything is looking pretty good. 

      • A couple things tripped me up about error reporting. 

      • Old library hid parallelism from you. If there is bad data,the exception thrown was human readable. “Can’t read scanline 32.”

      • Now, hard to tell what to report back when there’s an error.

      • Error messages are straight from the implementer. No user can understand them. 

    • Kimball: error messages are for me to figure out where the error was occurring, not for users. Should make a cleanup pass.

    • Larry: I want the earliest tile in the file. Don’t want the earliest one according to the clock, because that will make it hard to write a test suite that validates error detection. 

    • Just a very different behavior.

    • Kimball : The big thing is unlocking the concurrent paths.

    • Larry: My test so far: open file, read it all. Haven’t testing reading pieces of a bunch of files. 

    • Larry: Memory use is lower, haven’t figured out why. Significant savings. 

    • Kimball: I’m paranoid about allocating memory, I try not to.

  • Namespacing

  •  

    • Zip level: because we’re adding API, technically we should bump the version.

    • Larry: screw the rules, do what’s right.

    • To be backwards compatible, you want the so name to stay the same. 

    • The libtool people are the only ones who wrote up a halfway decent description of a policy.

    • Larry: I don’t have a problem backporting a feature as long as it doesn’t break compatibility, even if technical it breaks semver.

    • With the VFX reference platform, if we bump the minor version, nobody will use it for a year, or we put out multiple versions that go unused.

    • For the Zip change, we should just do it.

    • Kimball: I did run the ABI compliance checker, not 100% sure I’m running it correctly.

    • Larry:

    •  

      • For Imath, is this more complex than we need?

      • Something like: put the core Imath classes in an unversioned namespace; the only thing that really matters is the memory layout, which will never change; the operations may change.

      • We’re very close to being a header-only library.

      • The so name and the namespace should be the same, but they shouldn’t be the release number.