Attendance:

Discussion:

• Core work:
  
  

  • Kimball: want to switch all the writers, discovered ImfDeepTileOutput deep writer writing more data than it should be. Uncompressed deep tiles (probably no one does this), if on boundary of image, it writes as if it has full sample set. To fix that, whether to add a flag and enable save in legacy mode. But for people w/o the change, it would fail to read the file. Depends on tile size how much extra data is stored.

  • Kimball: Wants to take out legacy readers/writers and put into a test space for test cases.

  • Larry: could add another test case that runs all of OIIO's tests against Kimball's branch to catch more issues than just EXR tests.

  • Kimball: all of compressors are using the core compression routine. Final step decide what doing about Imf header. Radically change API or not.

  • Kimball: writing extra data bug for uncompressed deep tile probably been there since the beginning

  • Peter: only a couple kb of extra data, more confusion for anyone using a different library. Could fix it in a different compression type.

  • Kimball: deep supports uncompressed, RLE and zip. situation is that the current behavior is different from what the spec says. 

  • Cary: downside of including the legacy readers/writers in test space is it makes the downloaded source larger. Put them in the test instead of the library. If compile lib without the tests, not bothered by it. Should not be in the distributed version. Unless it's helpful for the external version.

• New Python bindings

  • Cary: finally submitted the new bindings. If everyone could look through the python examples in particular.

  • Cary: where Lucas left off is where we are now. 

  • Larry: Imath classes will be a breeze compared to the OpenEXR classes,

  • Cary: maybe trim that stuff out of the bindings, so bindings are minimal set of what you need, keep the rest internal to ILM

  • Larry: probably fine to drop Alembic-needed parts of Imath Python bindings.

  • Cary: needs help from Peter, confused about writing deep data, how to deal with sample data, what kind of memory layout is it expecting.

  • Peter: quite versatile in what it expects, deep image being an array of lists, might want to support that directly. This would probably force you into a specific data layout.

  • Cary: need help with ID manifest and pixel subsampling stuff - x-sampling, y-sampling.

  • Kimball: sampling is weird multiple, where the samples occur is always based on 0,0 in the virtual global space, look at abs of (missed this) when mod 0 you have a sample 

  • Peter: mult sampling by the pixel stride, you can do that by setting the x stride. but can also set it up so it packs the data into a 50x50 array

  • Peter: kind of incomplete specification, can't specify which pixel it lands on. Can set samples on anything you like. e.g. can set it to the tile size so AOV can be stored by tile.

  • Cary: also need help with - option to just read header and return, don't read pixel data, nice if you just want metadata, would be nicer to record it back so if you write it out it would copy the raw pixel data over. 

  • Kimball: shouldn't be difficult using the C++ API. reopen input file, copy pixels, copy input to the output. 

  • Kimball: core is deliberately low level, not have API bloat, for tiles should be able to get number of levels, number of tiles, loop. Chunk I/O does a lot of figuring out for you.

• Imath binding location

  • Larry: took target out generated cmake config in previous PR, should have been avoided by fixing the other bug, putting module in the wrong place entirely, doesn't think it uses the correct naming convention, confused about right way to do it. Cascade of issues - CI not testing Python bindings on Windows and Mac.

  • Larry: not expert in Python, concerned about missing something.

  • Joseph: if moved to PyBind11, if installing packages, can I have one set of installed libraries

  • Kimball: technically could use a single version of Imath

  • Larry: but we're still tied to a specific version of Python, past 3.12 and on nanobind won't have to build copies of library for each Python

  • Joseph: still have to build Python parts of library, at least it won't have boost

• Core , next release in September

  • Cary: what is in the new branch is completely functional, could make a release out of what's there now?

  • Kimball: yes but needs more testing, each PR represents change in stable ..., have not changed the API yet

  • Cary: looking toward September release. Z-standard compression willing to put in next release?

  • Kimball: that would make an OpenEXR 4 Release. Core changes do not necessitate major version increase though. There will be a lot of dead standalone function, no longer used internally. Talked about putting deprecation flag on those for a release or two. Before removing them.

  • Cary: should get on with validating new compression type, bumping file version only when necessary

  • Peter: we've added new compression types before, e.g. 2.1 DWA added. Works fairly smoothly, no extra flag. It does the check at file header read time. 

  • Kimball: Old libraries will safely fail. Like to introduce single version map to core library and start locking down the core ABI. Not sure if we do the C++ side at the same time.

  • Peter: those changes don't mean you need to edit any code to compile. From library point of view, not a major bump. Could do a version 4 this year and version 5 next year. Being able to rewrite metadata or append to end of file - would be a major change to add these. Could be in its own bump later on.

  • Cary: doubt we would accomplish that before September. 

• Blosc

  • Kimball: new dependencies are a concern, Blosc: could vendor in the source (not a great solution), could do same thing as we did for deflate, could drop in the new compiled library, don't need to recompile EXR again if it's building separately.

  • Nick: is Blosc small, does it have exotic build stuff?

  • Kimball: there are dependencies for testing kit, but don't think library itself has many dependencies

  • Cary: should get on with merging it in and resolving any issues

  • Kimball: proposed patch is from Philippe and Vlad - they didn't propose patches to the core.

  • Cary: think they added patches to the core.

  • Peter: confusion over multi deep scanlines... there should be a single deep scanline version of it at least.

  • Nick posted link to lib: https://github.com/Blosc/c-blosc/tree/main/blosc , looks small

• Python

  • Cary: could check with TAC to see if anyone has an informed position about where Imath python bindings library should be installed and what the name should be for newer Python

  • Larry: weren't putting it in the site packages before at all, but what should be embedded in the name.

  • Kimball: newer rules about where python looks

  • Larry: might be different on different platforms

• OpenSource days talk

  • 25th anniversary of the start of OpenEXR

  • Kimball: submitted talk proposal : "how do we make OpenEXR last for 25 more years", may need help pulling up some help with history

  • Nick: believes it is put on the schedule