On 2020-02-08 05:28, Peter Hillman wrote:
I've always thought of classes like Chromaticities and Timecode existing in OpenEXR largely so they can be written and read as attributes in OpenEXR, and the library itself not supporting advanced methods for manipulating the data they represent.
Adding an epsilon to the Chromaticities gets us dangerously close to OpenEXR being a library that does color management/color science.
That feels like feature creep, and maybe OpenColorIO is a better project to take on that logic, or perhaps an additional independent library that understands OpenEXR, ACES workflows and OpenColorIO.
Agreed. OpenEXR should be a dumb/agnostic container. Having an operator== is OK (as long as it checks white as well), but anyone using it to see if a file is in a known colour space will need to do a looser comparison.