[sane-devel] Re: sane-devel digest, Vol 1 #807 - 11 msgs

Stéphane VOLTZ stefdev@modulonet.fr
Wed, 22 Jun 2005 06:51:59 +0200


Le Mardi 21 Juin 2005 23:35, Nightwulf a écrit :
> Hi,
>
> Am Dienstag 21 Juni 2005 07:34 schrieb
>
> sane-devel-request@lists.alioth.debian.org:
> >         The test16.pnm picture you posted is perfectly =
fine (I'm using
> > Imagemagick to see it). The trouble you get is related to the image
> > viewer you use. After trying konqueror to display it, I saw the same
> > artifacts you get. So it's a kde a bug related to 16 bits pictures.
>
> I doubt that Stef...I tried to open the pic with gimp 2.2 and I get an
> error message "PNM: invalid maximum value". So there really seems to be
> something wrong with the pic. Perhaps Imagemagick ignores some header
> information or is more liberal while dealing with damaged pics.
> I can't say of course wether it is a failure of the backend, the image
> library or whatever.
>
	Believe me, the image is right. You can enable 16 bits scan in xsane by
enabling 'stand options window'. The internal image viewer will show you nice
looking pictures. Furthermore, you can convert the 16 bits picture into 8 bits
with the command 'pnmdepth 255 test16.pnm >test8.pnm' . The test8.pnm
picture will be OK in any image viewer. I think we can trust the pnm utilites 
about their own format. gimp and eog simply don't know how to handle 16 bits 
pnm, and kde image library has some bug.

> >         For the other bug -trying to scan outside usabl=
e area- bound
> > checking is done. I think it may be a bug in scan area origin detection
> > bug. Origin may be wrongly detected a few mm too much toward "buttons
> > side", so the scanning head goes to far. You may check it by scanning a
> > triangle shaped paper, with one corner touching the very top of the
> > scanning area. If expect that a few mm of it will be missing.
>
> Tried that and found that you are right. The topmost part of the edge is
> missing until I set the size to A4.
>
> >         You may also wait ~45 s after powering before t=
esting. I think
> > origin detection may fails if scanner isn't warm enough.
>
> I remember how long it took under windows to do the first scan. It was
> approx 1 min while the program said "warming up lamp". Is there any
> possibility for the backend to force the frontend to block scans or give
> error messages? I did not encounter any hangup in approx 5 test scans inc=
l.
> preview after I started to wait 1 min after the initialization of the
> scanner.
>

	OK, I'm going to add a 1 minute timer in the backend to prevent hanging.

> >         When all debug is activated, the backend write =
debug pnm files
> > containing data is scans. I'd like to have these:
> >         - search_position16.pnm
> >         - search_position.pnm
> >         - laplace.pnm
> >         - xsobel.pnm
> >         - ysobel.pnm
>
> I deleted those pnm's already so I did another scan with full debug and p=
ut
> the pic, the log and all debug pnm's into a tar.gz:
>
> http://www.night-wulf.de/debugmaterial.tar.gz
>
> So I think there is no serious bug remaining. The picture format bug can
> only be a small failure in the header since xsane viewer and imagemagick
> show the pics allright and the warming up is a matter of simply knowing i=
t.
> If you can do something about it, it would be great since it would solve
> the origin detection problem too.
>
> Thank you very much for your great work Stef!
>
> Greets,
> Torsten

	Thanks for the datas. An updated backend will be available in CVS soon.

Regards,
	Stef