Re: Imf::Chromaticities::operator==

Piotr Stanczyk

HI Cary, 

Doesn't look like looking through the commit history is triggering anything; those are just merges along the way.  Indeed taking a step back a few years (decades?) I see the following on Savannah. ;

Stepping through the diffs there it looks like this one dates back all the way to the first public release.

Revision 1.1 - (view) (download) (annotate) - [select for diffs] 
Tue Dec 2 03:06:21 2003 UTC (16 years, 2 months ago) by dhess 
Branch: MAIN 
Branch point for: OPENEXR_1_0_7_PATCHESlossy
* Support for new "optional standard" attributes (chromaticities, 
luminance, comments, etc.). (Florian Kainz, Greg Ward, Joseph Goldstone)

I rather think we should rework this. As Phil points out, the floating point comparison here is ready to haunt us and we are indeed missing the white point.
I would be tempted to settle on a tolerance to account for some common round trips, e.g. P3 -> sRGB -> P3 and some white point adaptation matrices.  

Phil, I don't have the numbers in front of me, but do you know what the maximum delta-E is for a 4 decimal place perturbation?


On Wed, 5 Feb 2020 at 17:33, Cary Phillips <cary@...> wrote:
Piotr, it looks like you contributed these functions, although I can't tell if you were the original author or just did the merge.  Do you recall anything about the logic of the comparison operators and the white channel? 

Thanks for any insight.

- Cary

On Tue, Feb 4, 2020 at 3:16 PM Cary Phillips <cary@...> wrote:
Arkell Rasiah posed, the question, is there a reason that the Imf::Chromaticities comparison operators ignore the "white" channel? Is this intentional, or an oversight? Anyone have any recollection about the logic?

Chromaticities::operator == (const Chromaticities & c) const
    return red == && green == && blue ==;

Comment here or at

Cary Phillips | R&D Supervisor | ILM | San Francisco

Cary Phillips | R&D Supervisor | ILM | San Francisco

Join to automatically receive all group messages.