Attendance:

Agenda:

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.

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.

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.

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.

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.

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.