Attendance:

Guests:

• Li Ji, ILM

Discussion:

• Repology ((https://repology.org/project/openexr/report) 

  • Useful for identifying distros using old versions of our repos

  • Chart of versions in use in current distros has been added to ReadTheDocs / OpenEXR website. (https://openexr.com/en/latest/install.html#install)

  • Compared to other repos, there is similar adoption.

  • Confusing chart because it is listing old distros versions which would of course have old OpenEXR versions.

• New release is out, went out just fine.

  • Major part of work was python binding publishing on PyPi, nice to have it all in order now.

  • pip install openexr, bindings are linked against newest release now.

• On the horizon: next minor release

  • Cary: What will go in it - presumably new compression formats

  • Cary: Want to get it out before VFX reference platform update

• PR #1604 - Zstd compressor - Philippe Le Prince

  • Peter: Deep formats multi-scan line doesn't work, would require a lot of work to happen transparently

  • Peter: Idea is to do single scanline format for deep

  • Could make both single and multi scanline compression formats but only make single work with deep

  • Peter: issue with new compression type is that it will break all the old code

  • Peter: so can say new compression types added in a particular version rather than giving people a table to track

  • Rod: recalls Kimball proposing we might have to go to v4

  • Peter: didn't go to 3 when DWA was introduced

  • Li: is this the C++ or core library?

  • Peter: both (core then C++ would use it)  

  • Peter: one issue - need to add to internal compression API so compressors understand the deep format better, lack of this flag makes compression less efficient for deep, should make this change before added new compressor into library

  • Peter: zstd API doesn't allow for variable sized data so it will have to compress different channel types separately - up to 3 compression blocks per scanline for each data type stored. Doesn't work for deep because you don't know how many samples there are.

  • Peter: reason deep has a bigger file size is because it's harder to compress, fixed locations with deep.

  • Peter: need to quantize the depth force, all data to be on a voxel grid

  • Peter: interesting idea to uplift everything to float but would still need to change the API

• Nick: question re how C and C++ implementations relate on this point.

  • Peter: makes sense to have implementation in C core then create C++ wrappers. Should get roadmap out of Kimball regarding how to do this

  • Nick: more than a one person job

  • Peter: should NOT be implementing new code in both, there are certain places where it is hard to contain implementation only in the C core. example: Sgl container.

  • Li: if sure containers are read-only, could be encapsulated in the C lib

  • Peter: yes time/work to set it up. Could have hidden internal functions in C library that allows it to access C++ library data structures.  Will get Kimball's thoughts.

• Nick: nanocolor project update 

  • small set of analytic color operators - e.g. map between color spaces

  • propose small list of canonical set of core color spaces - small list of named spaces known to be true which could then be used in formats like OpenEXR

  • color spaces not well managed over the years

  • Joseph: white point vs chromaticities - 

  • Nick: specifically carrying both and the transfer operator, all EXRs on the ACES side carry AP zero.

  • Joseph: ARRI did correctly carry these aspects

  • Nick: alternative provided to carry the 3x3, fitted matrix - want to be able to carry fitted from measurements color space vs. theoretical color spaces.

  • Peter: one issue of using existing attributes to store this new data, perhaps should only allow writing that attribute stored separately in the EXR block (not in the header) so no one with older versions would inadvertently write the attribute, could add an extra bit to indicate the file has "signed" color in it. If you do that, can make a new attribute type that encodes everything together, but not multiple ones.

  • Joseph: if having a signing gateway, could enforce that the values are congruent 

  • Nick: don't think it's possible since it's just a fitted matrix

  • Joseph: that's how we did it with camera native, not yet converted by ARRI wide 3x3 fitted matrix. Came up with virtual primaries.

  • Peter: if writing code saying 3 things provided are consistent, why not just only provide one and compute the other 2 from the first value.

  • Nick: not sure how to do that in a reasonable amount of time

  • Peter: if you say I want to provide chromaticities plus the matrix, implementation could check that they are approximately in correspondence

  • Peter: seems that OpenEXR should support arbitrary chromaticities

  • Nick: nanocolor allows for that. Not allowed to give it the name that is reserved.

  • Nick: not meant to hamstring OpenColorIO, meant to say this is the minimum viable subset we need to work with. 

  • Nick: code is as small as possible.