CIELab-gamut-tools / gamut-volume-m

CIELab gamut volume calculation and visualisation in matlab/octave
MIT License
25 stars 1 forks source link

Another Distortion of Gamut Ring Intersection Rendering #8

Closed kenichiro-masaoka closed 2 years ago

kenichiro-masaoka commented 3 years ago

The gamut rings of sRGB.txt still have a small bump with the intersectionPlot true:

sRGB = CIELabGamut('sRGB.txt');
lcd = CIELabGamut('lcd.txt');
PlotRings(lcd,sRGB,'RingReference','intersection','intersectionPlot',true);
xlim([-250 0]),ylim([-250 0])

test3

When sRGB.txt and lcd.txt are swapped in the gamut rings with intersection, small bumps are also found:

PlotRings(sRGB,lcd,'RingReference','intersection','intersectionPlot',true);
xlim([-500 500]),ylim([-500 500])

test2

euan-smith commented 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.

euan-smith commented 2 years ago

Hopefully I can get to the bottom of this in advance of work on the itersection plot in the IDMS.

euan-smith commented 2 years ago

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.

euan-smith commented 2 years ago

OK, both fixes implemented in branch: image 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.