Attendance:

Guests:

• Pierre-Anthony Lemieux, Sandflow Consulting

• Michael Smith, Intel / Wavelet Consulting

Discussion:

• PR 1956, benchmarking

  • Peter made a start on total rewrite, didn’t reply to latest message yet, plan is to submit Peter’s version eventually.

  • Also trying to adopt some of the perf suggestions as well.

• Security policy

  • Open question: how far back do we patch bugs

  • Current document is out of date.

  • Cary: Accurate to say we will patch upon request. Although this may seem a little odd.

  • Peter: maybe other way around - we don’t automatically release patches for bugs as they arise except for 3.2 branch. Make it clear that just because documented fix, does not apply fix is in other branches.

  • Larry: shouldn’t guarantee but determine whether it is safe to backport when requested. Perhaps wise to define a certain number of years back that we will not support

  • Cary: no 1.0, maybe not 2.5.

  • Peter: advantage of making people request is that they will test it as well. Also people using older versions might not always be in a position to apply a patch.

  • Nick: “at project discretion” phrase captures everything succinctly.

• J2K branch merge - HTJ2K compressor PR Pierre-Anthony Lemieux

  • Pierre - any remaining blockers?

  • Pierre - introduces dependency on OpenJPH library. Currently imported directly from github. Comment to try to find on local system first.

  • Nick: libtiff reference but only need for tools so not needed in Imath build.

  • Cary: could follow Imath’s use of libdeflate for CI. Added CI to do one build which installs libdeflate and in another build does an internal build.

  • Pierre will use that as a template.

  • Pierre: latest updates now single compressor, removed extraneous parts. Any other concerns besides looking for libraries present on local system?

  • Nick: what is right behavior if you statically build OpenEXR - if internal, OpenJPH should be statically linked. Otherwise both should be dynamically linked.

  • Peter: if static, would it be included in the same library? Then don’t need an extra library?

  • Cary: orthogonal to build internal, link external. If static and built internal, everything is folded in.

  • Nick: if internal linkage, the symbols wouldn’t leak out.

  • Cary: external linking is the important case, that’s the case that Linux distro managers will care about. But we want internal build to work as well - that’s the academics' case, makes it easier for them.

  • Nick: if Maya is linked against something, don’t want to have to figure out what Maya is linked again - don’t have worry about cross-linking two different OpenJPH.

  • Peter: extra complication tools linking can’t guess what it’s linking against. Whether it has to link against external package or not.

  • Pierre: same applies to Imath and libdeflate.

  • Peter: true of libdeflate but Imath will be built if not found by OpenEXR.

  • Cary will look it over to help make the CI similar to the libdeflate example.

  • Nick: benchmarks?

  • Cary: Peter has been working on some framework for benchmarking but we need it across the board. Should not hold up J2K.

  • Nick: documentation? what are the characteristics of this compression, when should you use it or not.

  • Peter: should make a page on compression types that is artist readable.

  • Peter: should we do wider testing? so when it is officially announced we can back it up with people saying you should use it. Partly because of the extra dependency.

  • Pierre: encourage everyone to test PR.

  • Nick: could merge to a feature branch.

  • Cary: should be mentioned here: https://openexr.com/en/latest/ReadingAndWritingImageFiles.html#compression

  • Source here: openexr/website/ReadingAndWritingImageFiles.rst at main · AcademySoftwareFoundation/openexr

  • Cary: get last few issues worked out in next few weeks then make a feature branch. Then we can make an announcement and see how that goes. Then plan a subsequent release based on that testing.

  • Peter: need a warning that files make stop working if we change the binary.

  • Nick: important to get Kimball’s C-core change to a working state. Still running into breaking bugs. Don’t want to be in position where have a big format change across semi-working versions. Would like current version of OpenEXR that works so it’s releaseable before we add a file format.

  • Cary: that’s even more of argument for a feature branch. Make a release with Kimball’s fixes, then after that make a separate release with the new format.

  • Peter: the C++ API will remain stable. Kimball wants to change the writing side to use the core as well. Scarier if there is a bug on writing side. Want to get reading side stable first.

• Color Interop Forum

  • Nick: Carol & Doug (OpenColorIO TSC chairs) would like to attend next meeting to discuss color in OpenEXR as related to Color Interop Forum.