Attendance:

Guests:

• Li Ji, Industrial Light & Magic

• Michael Smith, Intel / Wavelet Consulting

Discussion:

• 3.3 release

  • Cary has it staged but publishing step is failing.

  • Security - make a patch release, once out for a while, will request CVE numbers

  • Would be good to use sanitizer ever release so when bug discovered, say which one have bug present.

  • Peter: can do that analytically, can use “blame” to identify when line of code was introduced.

  • Larry: only work sometimes, often interaction between multiple things. Hard to know how much work we should do to identify when bug was introduced.

  • Peter: should we be doing patch releases in old versions?

  • Cary: highlights benefits of exr-utility.

  • Peter: need to compile with latest version of exr-check that works with a given release.

• HTJ2K

  • Cary: once done, we should merge the HTJ2K branch in.

  • Peter: would be good to know performance characteristics, though not going to change our decision on whether to release it.

  • Cary: HTJ2K should be automatically brought in, configured for your situation when you build. Either do that or modify the link line to find a new library.

  • Peter: when it compiles, if it has pulled in the source, will compile into the EXR lib directly. No separate lib. If using the cmake config, automatically add library. If you’ve tweaked the build system would have a separate lib. Downside is we have to do more work to maintain updates.

  • Michael: If added JPH to the fuzzer project would that solve the issue?

  • Peter: essentially what we would need to do.

  • Cary: overview is: seems that it is making its way out to vendors, no feedback yet on results. Stepping forward toward merging.

• New release of Imath

  • Cary would like to make a new release of Imath, since we have control of PyPi project, want to set up wheel for Imath, unfortunately means need to get this working with Boost, not working on Windows.

  • Li: local build of Windows, could take a look.

  • Cary: CI wasn’t building python bindings on Windows at all, that is what is failing

  • Cary: brought confidence tests into pybind11 to make sure new wrappings replicate the old behavior. Want to get that in place before the next Dev Days so people can contribute to this part. That way they can submit a test to validate it’s been done correctly.

• Dev Days

  • Cary: should start thinking about projects for Dev Days.

• Loss compression comparison tool?

  • Michael: is there an exr comparison tool for example for lossy compression, for measuring compression distortion. Relevant since we considered working on lossy compression for HTJ2K.

  • Larry: not in OpenEXR per se. OpenImageIO has it.

  • Peter: don’t even have a lossless comparison. e.g. pass 2 framebuffers, verify that they are identical.

  • Larry: would be a good addition.

  • Michael: also useful for regression testing.

  • Cary: worthwhile tool but don’t have rich set of tools because they exist in OpenImageIO.

  • Peter: interesting looking at loss because it’s not the final image. You don’t know whether it matters. e.g. really bright values get clamped to 1 in display LUT.

  • Larry: when using DWA compression, images that look similar there is considerable loss when there are values greater than 1.

  • Li: if talking about loss, need to know what the consumer of the image is.

  • Peter: wonder if this gets beyond the scope of what EXR should do. Starts to move into OpenImageIO territory.

  • Joseph: more OpenColorIO territory b/c it’s perceptual metrics.

  • Peter: but OpenColorIO doesn’t do opening and saving of images.

• ASWF pipeline project?

  • Joseph: is there a project that looks at pipeline as a whole? also metadata loss as things go through the pipeline. Thinking about tools to help but if already a project. Peripheral concern for so many projects but not the focus of any of them.

  • Larry: first problem is each tool along the way has a different convention for how it interprets the metadata. Hard to coordinate between projects.

  • Joseph: as we do interproject coordination, making sure it doesn’t get lost becomes important. e.g. SMPTE cam-D kit project, trying to get multiple vendors at different parts of the pipeline use standard naming and semantics.

  • Larry: thorn in side of OpenImageIO, idea to have agnostic way to read image formats but they all have different naming conventions.

  • Joseph: so many metadata schemes, yet “perfect should not be an enemy of the good”.

  • Peter: diff won’t tell you there is an attribute missing, might want to report that an attribute has changed its type.

  • Joseph: RED stores metadata as strings. SMPTE cam-D kit provides for different vendor encodings to map into common python objects, but no mapping from that to any particular file format metadata scheme. Thinking of writing one for OpenEXR but would have same namespace problems we have today.

  • Peter: we chose not to namespace it.

  • Larry: do we tell them to namespace if they add a non-standard attribute?

  • Joseph: in ACES container spec, there’s a promise that standard attributes don’t have a period. That’s how he did things at ARRI, encouraged codecs to do the same. Can fix 90% if you convince Carfront, filmlight and blackmagic design to do the right thing in transcoder, baselight and resolve. If vendors exposed to Cam-D kit … blackmagic did not participate that.

  • Peter: don’t think there is any mention of namespaces in documentation or header files. RGBA interface it talks about layer and channels. We could put some helper functions, like one that returns the namespace so it’s an official thing.

  • Joseph: how many vfx pipelines use attributes in EXR files vs cramming something into the filename?

  • Peter: Nuke overenthusiastic, namespaces all of its attributes.

  • Larry: … and uses forward slashes rather than dots.