toggle quoted messageShow quoted text
I think STL has issues with poorly
defined '<' operators, and gets in a real mess when a<b and
b<a both return true. I imagine a<b and a==b both returning
true is also dodgy, which could happen if a non-member '<'
operator is defined which considers white, when == doesn't, or
when == is approximate.
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
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
On 8/02/20 7:00 am, Joseph Goldstone wrote:
I meant to say would not Redefining operator==, obviously, in the
particular “within epsilon” way suggested below.
Would not defining operator== for
Chromaticities break STL containers of those objects? They
use operator== to determine whether two objects are the
same, in managing the elements of ordered and unordered
sets, maps, etc. If you make it so that an effort to
insert a Chromaticity that is really close to an existing
Chromaticity is instead a no-op, I could see bad
consequences for that.
In our own code do we compare
floating-point numbers in Chromaticities for equality? If
we really have a distance that’s “close enough” in either
a radiometric or photometric space, that seems like it
should be expressed as an operation of its own and not
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]
Dec 2 03:06:21 2003 UTC (16 years, 2 months ago) by dhess
CVS Tags: HEAD, OPENEXR_1_0_7, OPENEXR_1_1_0, OPENEXR_1_1_1, OPENEXR_1_2_1, OPENEXR_1_2_2, OPENEXR_1_3_0, OPENEXR_1_3_1, OPENEXR_1_3_2,OPENEXR_1_4_0, OPENEXR_1_4_0a, OPENEXR_1_7_0
Branch point for: OPENEXR_1_0_7_PATCHES, lossy
* 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
On Wed, 5 Feb
2020 at 17:33, Cary Phillips <cary@...
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
Thanks for any insight.
On Tue, Feb
4, 2020 at 3:16 PM Cary Phillips <cary@...
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
red == c.red && green ==
c.green && blue == c.blue;
Comment here or at https://github.com/AcademySoftwareFoundation/openexr/issues/651
Phillips | R&D Supervisor
| ILM | San Francisco
Phillips | R&D Supervisor | ILM
| San Francisco