Attendance:

Guests:

• Thomas Wilshaw, Olive video editor contributor

Discussion:

• Townhall upcoming 8/1 

  • Cary shared slides for the agenda

    • OpenEXR v3.1 review

    • OpenEXR v3.2 release preview

    • Discussion topics

      • GPU decompression - Epic Games - Rod and Rus 

•  

  • Kimball: perhaps discuss roadmap, fits with GPU decompression

  • Cary: worth revisiting longer term objectives

  • Kimball: cover ABI stability issues

  • Larry: goal for the C++ interface and request for volunteers, mention conversion to PyBind11 still pending and hopes that more of the EXR side of library could have python bindings.

  • Cary: recent build issue came in from ppl who maintain PyPI would be good to bring them into the fold on this effort.

  • Cary: Emily Olin will be sending out communication, we should do that in our channels too

• ABI changes / versioning

  • Kimball: with Imath simpler approach to get to same end result to disconnect the namespace. Started Imath namespace changes, just to a stable namespace, taking version out is easy. Just a cmake file change and a few small cleanups. One option - put namespace Imath_v1 then in main Imath space "template<type T> using Imath_v1::box<T>" if we want a true versioning of the implementation but likelihood of changing is so small probably not worth it. So removing the version seems simpler.

  • Larry: most basic types haven’t changed in 16 years. Probably seems safe.

  • Cary: still leaving it as a macro, so if you chose to build with some other namespace you could.

  • Kimball: release process gets simpler, stop changing the so version.

  • Cary: so version: reached out to David Wheeler about his doc from 20 years ago, he said ask the package managers. Didn’t say what alternative to the libtools versioning policy is. Now understands what numbers after .so means and what the libtools process does.

  • Kimball: numbers have no bearing on so name that ends up in headers.

  • Cary: libOpenEXR.so.3.0 <- 3.0 is important, the numbers after are arbitrary

  • Peter: symlink implies ABI compatibility with previous versions

  • Kimball: other layer is symbol versioning (difficult for C++) for C, elfmap to map to 2 different versions of the same function, and can set the default. Symbol you link against has a version number. It does the name mangling for you, adds a tag with {} block of text. To generate the v1 and v2 in C++, you have to have the mangled name in the source file when you create the alias, by contrast to C. readelf on libstd++, you see the symbol versions. C++ lib are good about symbol versioning for backward compatibility but it requires being mindful so many other libs don’t do it. 

  • Cary: I would be concerned about getting this wrong.

  • Kimball: we could do the so version but don’t try to do the symbol versioning.

  • We’d put the OpenEXR version of .so. Just need to not change the first digit, this gets embedded. For dynamic loader, the version can be whatever you want so just follow convention and make them increasing. If ABI compatible we can leave the version alone.

  • Peter: if add new function, do we need to bump major version. Because it is breaking.

  • Kimball: this is where you want the symbol versioning. 2 sides of coin, do you support older programs linked against older lib versions or not? It would benefit us to start doing that

  • Larry: some of the others just straightforwardly use the release number but enforce compatibility. Simplify so naming.  So.5 - base it on the 3 digits of the software release but don’t have the libtool set of rules. e.g. libOpenImageIO.so.2.4

  • Kimball: basicall a symlink from libOpenImageIO.so.2 to 2.4 

  • Larry: Cmake sets it up for me.

  • Peter: but if 2.5 comes along with ABI breaks, you have to recompile everything

  • Larry: yes ABI breaks allows 2.4->2.5 but not 2.5.3->2.5.4

  • Peter: distinction between changing a symbol and adding one. If you add new symbol do you have to bump the minor version.

  • Larry: we do that, packagers don’t complain so far.

  • Peter: if writing against new function, need to check the version on the system has the new function.

  • Kimball: package maintainers are largely dealing with backwards compatibility issues.

  • Larry: don’t maintain forward compatibility and so far not a problem

  • Cary: Propose we go with Kimball’s rec, so version will bump when there is an ABI breakage. Will write up and share with package managers.

  • Cary: DWA test failure, would like to have a fix before releasing.

  • Kimball: needs to find a platform to test on.

<Kimball had to leave>

• OpenEXR PR #1473 - consolidate project configurations in one place

  • Nick: going to finish off PR which needs a few more fixes.

• OpenEXR Issue #1485 - errors building OpenEXR in gimp 

  • Nick: we can just add in the missing C types. Should fix their Fedora issues. Windows-side seems like a legacy issue with some bad assumptions. May be building with C++11, seems like they have scripts that need updating, not sure how far we want to go into looking at gimp tools. Tried to point them in the right direction.

• OpenEXR Issue #1450 generate DLL for x86

  • Nick: basic cmake issue, it’s been a month, seems like someone learning to do development on Windows 

  • Cary: will ping and close out old issues.

• OpenEXR Issue #1391 - new attribute to detail exact physical dimensions of display window

  • Joseph: Need to account for sensor not being centered. Usually small amount but it matters. Looking at tech intro to OpenEXR diagram relating screen window to display window. Does anyone recall rationale of centering offset?

  • Nick: is it no the center of projection?

  • Joseph: that would be origin? Film cameras always try to center the film gate in the lens mount. So this is accounting for a film camera that hadn’t been quite true.

  • Nick: could be a mask over an aperture.

  • Joseph: asked Rod a few years ago, he couldn’t remember why we had this either. Also issue of units - are they in pixels or normalized coords of screen window or …? This is last thing I need to resolve before 3.2 freezes and becomes part of the reference platform. 

  • Nick: it’s a thing in camdkit.

  • Joseph: not sure that camdkit has centering offset. Something you find in Cook’s lens model. Camdkit was supposed to be superset of Cook’s and ARRI but does not have it. It’s going to have to go into camdkit2… so an even bigger headache. Trying to reconcile to fit well into existing OpenEXR paradigm is difficult. 

  • Nick: camdkit is a rare repository of some set of consensus

  • Joseph: entrance pupil position in camdkit is unsigned, grievous error but they do not respond. Urgent issue is this because of upcoming deadline. Will try to come up with proposals and solicit comments from the group.

  • Nick: if display or data windows don’t match exactly, can’t find 2 applications that do the same thing. If we add more on top of that interpretation it will further obfuscate. Rather have something simple and clean. Trying to add something on for new requirements since I don’t understand the old one, very confusing. No strong distinction between metadata and important things you must have to read the file. Everything comes from attribute bag.

  • Larry: in addition to how do you display it, if you have 2 openexr files and need to do an “over” need a clear set of rules for how to interpret these values.

  • Nick: unclear what do with a tile e.g. when outside a window, what if not an even multiple, etc. Very complicated.

  • Peter: default image loader reads tiles into a scanline API

  • Nick: more or less what I have but don’t expect it to work outside of that rigid constraint.

  • Peter: when datawindow doesn’t start at 0,0 somethings are counterintuitive about how to read a file. Poorly defined what it’s offset from.

  • Cary: displaywindow only affects view of the data.

  • Larry: yes pure metadata. But very often if using EXR as a texture, many systems use displaywindow for mapping to texture coordinates.

  • Joseph: shared diagram from OpenEXR Technical introduction (Projection, Camera Coordinate System, and Screen Window) to discuss screen window vs display window.  

  • Cary: display window corresponds to full window but that is deceptive as it might be smaller.

  • Joseph: they should always be proportional. Issue is how does the screen window fit into that. Can’t tell whether the frustum is parallel to the Z-axis or not. 

  • Nick: might relate to entrance pupil

  • Peter: maybe speak to the 3d equalizer people

  • Joseph: yes, talked to Rolf but it’s been a while. Should touch base again. Will keep working on this.