Attendance:

Discussion:

If we had it to do over again (3.0 release): understand our downstream consumers
We should find what versions the standard distributions are on and encourage them to upgrade.
Kimball: I did that for v2.4
Larry: a good place to start: https://repology.org/project/openexr/versions
How do you find who the maintainers are?
Kimball: for Ubuntu, go into the package distros, it shows the maintainers
Kimball: Sometimes patches are useful/interesting, hard to discover that there are patches.
Cary: we should also meet with build engineers at Foundry, SideFX, autodesk.
Kimball: should we mutate the reference platform going forward?

Original motivation: encourage everyone to move forward
DCC’s are moving forward at different paces
Problem with different DCC’s doing things in a different way (with/without namespaces)
Don’t know which ones use libraries internally, vs. leading symbols.

Peter: primary outstanding ones are due to running out of memory. Deep allocates memory up front. Can open a deep image with the scanline interface.
A small file can allocate a huge amount of memory.
The test should take the same steps that pedantically written code should.
Don’t want the test to reject things that are wide.
Once it gets beyond a certain size, it pre-allocates.
Allocating a huge amount of memory up front might not be faster.
Should allocate along the way

Should the RgbaInput file should be quite limited. You get the yuv2rgb conversion

Kimball: we should push the global clang-format reformat.
Cary: Should rename master to main soon. Will send an announcement to openexr-dev.