Attendance:

Discussion:

Dev Days

• There was a lot of interest!

• Larry: OpenEXR may have had the most number of PRs

• PyBind11 - started by Lucas, his goal was to get the skeleton setup, will require more contributions to complete, 

• Cary: getting to 80% is easy, last 20% - arrays, buffer protocol less obvious

• Kimball: array/buffer protocol more native in modern pipeline

• Cary: Alembic is main other project that uses IlmBase, how much does community at large need

• Kimball: Weta uses the python bindings but it’s more the basic stuff

• Cary: looking at what ILM uses

• Kimball: should be optimizations of handling arrays or vectors, implement the NumPy equivalent as opposed to built-in arrays. NumPy may not have quaternions?

• Cary: Matt Graham was going to take a look at static build problem. Regression in 3.2.1 no longer finds libdeflate in FreeBSD. Seems to be a package config thing. OpenEXR builds ok but linking against it fails.

• Kimball: need 2 package configs to get fix it possibly. Need to emit the private variables to link against it.

• A few people had Windows build issues.

• Peter: perhaps we needed better instructions for how to set up on Windows to get the config to work. Should be consistent.

• Kimball: as a set of projects, we should have a centralized set of instructions for how to set up on each platform.

• Larry: some companies have very rigid build environments.

• Peter: how can we simplify contributions to non-code areas like docs.

• Larry: docs tend to go under the radar. I’ve written most of our project’s docs but we want it to be easy for someone to add docs when they’ve made major contributions. Not possible to preview until it’s merged in and readthedocs is run.

• Cary: occasionally people post a patch for an issue - a way for someone to make a contribution that isn’t in a PR.

• Larry: need a CLA.

Compressions types

• Kimball: had been talking with Rod about compression, but haven’t had time to write it up yet, not keen on adding all kinds of different compression libraries as dependencies, maybe we can make it optional

• Cary: could we do it with a plugin or callback

• Kimball: yes but compression type needs to be recorded in the file

• Kimball: GPU stuff they want is fine, direct storage header, create a header with these bytes in it, happens to match up to the one Microsoft uses, otherwise just normally deflate as you would, adding dependencies of bzip or whatever flavor of the month.

• Cary: do we want to make it easy for people to write files that only they can read

• Kimball: afraid about opening floodgates to any compression type, you can have opaque attributes, people won’t be able to read

• Cary: first step, make it so it’s relatively easy to add a new compression type in.

• Kimball: it’s easy enough now.

• Peter: might want to change - if it’s a new compression type, none of the files can be read because it doesn’t know how many scanlines are packed together. Don’t know how big its chunktable will be….

• Kimball: chunktable is in the attribute block.

• Peter: might need some enforcement. Got into a huge mess with the chunksize - it can be wrong since it isn’t enforced.

• Kimball: the reading library doesn’t use it

• Peter: but it would have to if it didn’t know what the compression type is.

• Kimball: could go to the last chunk offset and read from there

• Peter: should we make new compression attributes - put the scanlines per chunk into the compression ID. So first 2 bytes are # of scanlines and next 2 bytes are the existing ID.