Michael Schumacher writes:
> the "erase every other row" script-fu seems to be > broken. Sometimes, the wrong row is deleted. A sample image showing > this effect is available here:
> http://www.gimp.de/1044969327/1045147200/1045173183/streifen.png

Jean-Louis Hamel writes: > Conclusion: there is a bug in the last version of GTK+, probably a > rounding error when computing the dimensions of a selection rectangle > (or perhaps the feather option always applied...).

I can confirm this bug, but I find it very hard to believe that it would be caused by some bug in GTK+. GIMP's selections (especially when created programmatically, from script-fu, and not via user input) have nothing to do with GTK+.

It's easy to demonstrate the essence of this bug by creating a small image, say 10x20 pixels, zoom it up so you can see the pixels, fill it with black, and enter in the Script-Fu console:

; (this is a comment) Show the image's ID, assuming you have only one ; image open. If this is a fresh GIMP, it's typically 0 (aref (cadr (gimp-image-list)) 0)

; Show its single layer's drawable ID. Typically 2. (gimp-image-active-drawable )
; where is the number printed above

(gimp-rect-select 0 12 10 1 REPLACE FALSE 0) (gimp-edit-clear )

This should clear pixel row 12 to white, and does so.

(gimp-rect-select 0 14 10 1 REPLACE FALSE 0) (gimp-edit-clear )

This should clear pixel row 14, but in fact clears row 13!

Has anybody noticed this with a recent CVS GIMP 1.2 on Unix?

--tml

------------------------ Yahoo! Groups Sponsor ---------------------~--> Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/FpY02D/vN2EAA/xGHJAA/e4wwlB/TM ---------------------------------------------------------------------~->

List archives: To unsubscribe send a blank message from the address you're subscribed to

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

It turns out the bug is caused by Trio, the printf/scanf implementation included in GLib 2.2, and used on for instance Win32. (The main cause to use Trio instead of the C library's printf/scanf on some platform is that the C library doesn't have a C99-compatible snprintf() or positional printf parameters.)

When script-fu passes for instance the number 14 as a double to gimp, wire_write_double() uses g_snprintf("%0.50e") to write it out to the pipe as a string. g_snprintf() uses trio, which for some reason produces the string
"1.39999999999999991118215802998747676610946655273438e+01" (and not "1.40000000000000000000000000000000000000000000000000e+01", as I perhaps naively would have expected).

In GIMP, in wire_read_double(), this string is then converted back into a double in with the C library sscanf("%le"), producing 13.999999999999998. When this is converted to an integer in rect_select_invoker() when calling rect_select(), you get 13.

Sigh. I'll do some more testing and file a detailled bug report on GLib/trio. Or is this a bug in GIMP, should it do some tiny amount of rounding of the last significant digits in wire_read_double? I am no floating point expert, does that make any sense?

Or is the bug in Microsoft's C library? Should scanf()ing the above string produce the double 14, and not something a tiny bit less.?

--tml

------------------------ Yahoo! Groups Sponsor ---------------------~--> Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/FpY02D/vN2EAA/xGHJAA/e4wwlB/TM ---------------------------------------------------------------------~->

List archives: To unsubscribe send a blank message from the address you're subscribed to

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

(gimpwin-users readers can largely ignore this message... just keeping this thread there, too, as it started there)

Manish Singh writes: > It looks to be trio's fault, there is a bug similar to this opened already: >
> http://bugzilla.gnome.org/show_bug.cgi?id=101874 >
> Perhaps special case this on windows to use the native snprintf (I assume it > exists there). This isn't an issue in GIMP 1.3, since we don't transmit > doubles as text over the wire anymore.

Perhaps the simplest solution for GIMP 1.2 would be to change wire_write_double():

diff -u -2 -r1.14 gimpwire.c --- gimpwire.c 30 May 2000 23:38:46 -0000 1.14 +++ gimpwire.c 16 Feb 2003 01:20:28 -0000 @@ -437,5 +437,5 @@
for (i = 0; i < count; i++)
{
- g_snprintf (buf, sizeof (buf), "%0.50e", data[i]); + g_snprintf (buf, sizeof (buf), "%0.*e", DBL_DIG, data[i]); if (!wire_write_string (channel, &t, 1)) return FALSE;

I.e. don't use more digits than necessary, especially as some printf implementations (like Trio) might misbehave. (When asked for precision DBL_DIG, Trio does print 14 as "1.400000000000000e+01".) This might also improve speed a bit on all platforms, no need for the printf implementation to generate 50 digits...

BTW, what has been the rationale behind using floating-point for pixel coordinates in the PDB in the first place, for instance for gimp_rect_select?

--tml

------------------------ Yahoo! Groups Sponsor ---------------------~--> Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/FpY02D/vN2EAA/xGHJAA/e4wwlB/TM ---------------------------------------------------------------------~->

List archives: To unsubscribe send a blank message from the address you're subscribed to

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/