TSC Meeting Notes 2024-03-07
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.