Closed kenichiro-masaoka closed 2 years ago
It seems that this may be a subtle bug in the intersection itself. Not enough to cause any significant errors in returned gamut volumes, but enough to show up in the rings plot. I'll continue to try and dig into this.
Hopefully I can get to the bottom of this in advance of work on the itersection plot in the IDMS.
So the root of the problem is that some of the entries in the cylmap property are malformed. e.g. lcd.cylmap{61,248} has entries [1, 47.05; 1, 47.14; -1, 47.15], the entries should always only ever altenate +1/-1 (representing inward and outward facing surfaces). In calculating the volume and rings of the lcd gamut it makes little difference as the close-by inward surface cancels it out. However it breaks the intersection algorithm. So options are to either cope with it in intersection, or to prevent it occuring in the first place. I'll look to doing both.
OK, both fixes implemented in branch: it has slightly lowered the intersection volume, however probably a. correctly (those spikes will have added to the volume) and b. only by ~0.1% so nothing significant.
The gamut rings of sRGB.txt still have a small bump with the intersectionPlot true:
When sRGB.txt and lcd.txt are swapped in the gamut rings with intersection, small bumps are also found: