Le Mardi 21 Juin 2005 23:35, Nightwulf a =E9crit=A0:
> Hi,
>
> Am Dienstag 21 Juni 2005 07:34 schrieb
>
> [email protected]:
> > =A0=A0=A0=A0=A0=A0=A0=A0The 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 ni=
ce
looking pictures. Furthermore, you can convert the 16 bits picture into 8 b=
its
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 utilit=
es=20
about their own format. gimp and eog simply don't know how to handle 16 bit=
s=20
pnm, and kde image library has some bug.
> > =A0=A0=A0=A0=A0=A0=A0=A0For 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.
>
> > =A0=A0=A0=A0=A0=A0=A0=A0You 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.
> > =A0=A0=A0=A0=A0=A0=A0=A0When all debug is activated, the backend write =
debug pnm files
> > containing data is scans. I'd like to have these:
> > =A0=A0=A0=A0=A0=A0=A0=A0- search_position16.pnm
> > =A0=A0=A0=A0=A0=A0=A0=A0- search_position.pnm
> > =A0=A0=A0=A0=A0=A0=A0=A0- laplace.pnm
> > =A0=A0=A0=A0=A0=A0=A0=A0- xsobel.pnm
> > =A0=A0=A0=A0=A0=A0=A0=A0- 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
