Color bug

[lagroue]

While playing, I found a bug.
Some black CIRCLES are drawn, when they should not.

In the code below, there are three comments which may help target the nasty thing.

Code: Select all

startshape scene { color }

rule scene {
	# change hue here to change the height at which the blakc things appear (especially with negative hues)
	scene1 { hue 0 saturation 1 brightness 1 }
}

rule scene1 {
	poil { s 0.4 1 r 90 saturation -0.5}
	# remove the hue here to make the bug dissapear
	scene1 [ s 0.96 0.9 y 0.1 hue 1 saturation -0.01 ]
}

rule poil {
	CIRCLE { }
	# remove the hue here to make the bug dissapear
	poil [ s 0.9 x 0.5 hue -0.1]
}

[MtnViewJohn]

That looks like a bug in the HSB to RGB color space conversion code. I will check it out.

[MtnViewJohn]

Shows you how much I know about IEEE floating point. Apparently the code

Code: Select all

    while (hue >= 360.0) hue -= 360.0;
    while (hue <    0.0) hue += 360.0;
    int hextant = (int)(hue / 60.0);

Does not reduce hue to the interval [0,360). Thus, the hextant was not in the range of 0 to 5. Rather than try to force the interval to be correct, I added support for hextants -1 and 6. I will upload a new binary this evening when I get home.

[aaronstj]

Apparently the code

Code: Select all

    while (hue >= 360.0) hue -= 360.0;
    while (hue <    0.0) hue += 360.0;
    int hextant = (int)(hue / 60.0);

Does not reduce hue to the interval [0,360).

Why not? It looks like it should to me...

[MtnViewJohn]

If the hue is negative but very, very small then the second while loop will add 360.0 to it. Adding 360.0 will shift all the mantissa bits of the hue off the end of the result mantissa and you end up with 360.00000000000000. The odds of this happening are incredibly small. It is amazing that it happened so soon after release of the buggy code. Replacing the while loops with

Code: Select all

double hue = fmod(h, 360.0);

fixes the problem. I will keep in support for hextant -1 and 6 just in case.

[aaronstj]

Wow. Floating point roundoff is evil.

[MtnViewJohn]

Yes it is, and the HSB to RGB code is fragile with respect to rounding corner cases. I just realized that fmod(hue,360.0) isn't going to work for negative hues because fmod(x,y) has the sign of x. I think the following code is robust:

Code: Select all

   // Determine which facet of the HSB hexcone we are in and how 
	// far we are into this hextant.
   double hue = h; 
   double remainder, hex; 

	while(1) {
		remainder = modf(hue / 60.0, &hex);
		if (hex > -0.1 && hex < 5.1)
			break;
		if (hex < 0)
			hue += 360.0;
		if (hex > 5.5)
			hue -= 360.0;
	}

	int hextant = (int)(hex + 0.5); // guaranteed to be in 0..5

It guarantees that hextant and remainder are mutually consistent in their derivation from hue, that hextant is in the integer interval [0,6), and that remainder is in the interval [0,1). Adding 0.5 to hex before converting to an integer is probably not necessary.

[MtnViewJohn]

OK. The fixed (Windows) binary can be found at http://www.ozonehouse.com/ContextFree/C ... ree_v6.exe. Is that what you use or do you need Mark to build a Mac binary?

[lagroue]

Apple guys like I am will be pleased
(Downloaders of pictures I put in the forums are 77% MS, 19% Mac, 3% Linux (and 50% Firefox for those who are interested in this animal, 27% MSIE, 16% Safari))

[mtnviewmark]

Apple guys rejoice: There is a new version of 1.2 up with the hue fix.

Windows folk can rejoice too: The 1.2 installer for windows has been updated to include the new .exe with the hue fix.

[lagroue]

thanks !

[shevegen]

Oh dang we Linux users are greatly outnumbered.
Might prove a point that we are geeks, not designers (if anyone cares about generalizations that is...)

Nice ratio about Firefox though !

[MtnViewJohn]

The source trees (zip and tarball) both contain the color bug fix.