Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

You may have found a bug.  OK, let's see.

I haven't looked at any data or examples, but my initial suspicion is tha=
t although the following

> line 3777 : fprintf(gppsfile, "%d %d translate\n", corner[0].x, corner[=
0].y);
>=20
>     Why %d and not %u ?

is a conflict, unless corner[0].x is very large (i.e., the highest bit ch=
anges from 0 to 1) it will not print an incorrect value.

I do notice that corner.x and corner.y are unsigned int as part of gpiPoi=
nt.  In 'graphics.c' there is map_x() used to assign a value to corner.x =
.  However, map_x() is

#define map_x(x) AXIS_MAP(x_axis, x)

#define AXIS_MAP(axis, variable)		\
  (int) ((axis_array[axis].term_lower)		\
	 + ((variable) - axis_array[axis].min)	\
	 * axis_array[axis].term_scale + 0.5)

I.e., not unsigned.  So there may be a problem here.  I think it wouldn't=
 be unlikely that somehow this could be a negative value, if only due to =
rounding or whatnot.

So the question here may be What world should corner.x and corner.y live =
in?  Signed or unsigned?  I'm not sure I put too much thought into this o=
riginally.  I may have just patterned the function after that for filled =
polygons

_filled_polygon(int points, gpiPoint *corners)

I'll have to look at this when I have more time.

Thanks,

Dan


Ga=EBl Varoquaux wrote:
>     I have found a strange behaviour of the image code.=20
>     Here is a minimal example :
>=20
> set xrange [-10:137]
> set yrange [-10:157]
>=20
> unset colorbox
> plot 'blutux.rgb' binary array=3D128x128 flip xy \
> format=3D'%uchar%uchar%uchar' every 64:16 using ($1+$2+$3) with image
>=20
>=20
> With the standard terminal drivers (x11, post, png) this works without =
a
> flaw, but while working on the povray terminal, on the image code, I no=
ted
> that corner[0].x ends up being negative ! But it is a unsigned int !!
> The other terminals use it by calling it "(int) corner[0].x", thus
> forcing the conversion to a negativ integer. However if I put a=20
> "fprintf(gpoutfile, "corner[0].x : %u\n",corner[0].x)" I get a
> ridiculously high value printed. Printing it as an integer solves the
> problem, and this is how I worked around this.
>     I suspect this problem is lying around in other places (I think I
> might have seen it elsewhere, but it is hard to trick gnuplot into
> making a negative value for a coordinate). Maybe those "(int)" casts in
> many of the terminal drivers are just hiding more bug.
>     I just had a look at the way the post terminal calls this :
> line 3777 : fprintf(gppsfile, "%d %d translate\n", corner[0].x, corner[=
0].y);
>=20
>     Why %d and not %u ?
>=20
> 	I am wrong or is there a problem here ? Maybe these should not
> be unsigned ints, but ints ? Checking for there sign seems a bit
> complicated.
>=20
> --
>     Ga=EBl
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20
>=20


--=20

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/