# gimp plugin weirdness (workaround included)

=?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= (mikko@dynas.se)
Tue, 10 Mar 1998 21:25:59 +0100 (CET)

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Bjoern Chyba: "SANE"
- Previous message: Hugo van der Kooij: "Re: PB compile sane-0.71"

Hello!

I've had problems running xscanimage as a gimp plugin while using the
snapscan backend. I have sort-of found the problem, but can't really
figure out which part of the code to "blame".

What I'm using:

Agfa Snapscan 310
sane-0.71
gimp-0.99.18
gtk-0.99.3
FreeBSD 2.2.5

Symptoms: Running xscanimage as a gimp plug-in will hang the
xscanimage process when the scan is done.

I located the problem to xscanimage.c:scan_done(). When it writes the
last, partial, tile it has a line count that is off-by-one -- it
somehow believes that it has an area that is one line larger than the
actual image. This eventually causes an endless loop in
gimp_pixel_rgn_set_rect(), which makes sure it is not writing outside
its buffer (or tile or whatever).

Applying a sanity check like this works around the problem:

--- xscanimage.c.org Sat Feb 28 16:08:58 1998
+++ xscanimage.c Tue Mar 10 19:01:46 1998
@@ -771,6 +771,9 @@
int remaining;
/* GIMP mode */
+ if (scan_win.y > scan_win.param.lines)
+ scan_win.y = scan_win.param.lines;
+
remaining = scan_win.y % gimp_tile_height ();
if (remaining)
gimp_pixel_rgn_set_rect (&scan_win.region, scan_win.tile,
@@ -809,6 +812,9 @@
int height, remaining;
/* write the last tile of the frame to the GIMP region: */
+
+ if (scan_win.y > scan_win.param.lines) /* Sanity check */
+ scan_win.y = scan_win.param.lines;
remaining = scan_win.y % gimp_tile_height ();
if (remaining)

Right before a hang, (scan_win.y == scan_win.param.lines+1), which is
bad, and should not happen at all.

Am I really the only one with this problem?! (Rhetorical question...:^)

Looking at the code I don't feel entirely convinced that the way
xscanimage.c:advance() gets called when reading RGB data is correct,
but I wouldn't bet either way. (Well, I know for a fact that
scan_win.y gets incremented one time too many :-)

However, this has to be triggered by the way data is delivered by the
snapscan backend in RBG mode (perhaps hte way it always returns full
lines in each block, as it has to assemble the colour components from
a buffer), or users of other scanners should have seen it too.

At first I assumed the snapscan backend was at fault, but I have spent
quite a lot of time tracking it now, and feel fairly sure it is
behaving correctly.

Any helpful insights would be most welcome!

/Mikko

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Bjoern Chyba: "SANE"
- Previous message: Hugo van der Kooij: "Re: PB compile sane-0.71"