Attendance:

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.