Re: Backtracking in color scanning
Rogier Wolff (R.E.Wolff@BitWizard.nl)
Sat, 30 Aug 1997 09:30:10 +0200 (MET DST)
Rainer Krienke wrote:
>
> David Mosberger-Tang schrieb:
> >
> > >>>>> On Fri, 29 Aug 1997 17:04:01 +0200, Rainer krienke <krienke@mailhost.uni-koblenz.de> said:
> >
> > Rainer> When I scan color images at resolutions of say 300dpi the
> > Rainer> scan process works right, but is very slow. This is because
> > Rainer> the scanner scans some line and then goes back (that's
> > Rainer> backtracking if I understood it right) and then scans the
> > Rainer> next lines. Looking at the scanner it seems the the way the
> > Rainer> scanner goes back is just a little smaller then the way it
> > Rainer> has scanned before. Scanning a paper of size DINA4 (~30cm at
> > Rainer> length, ~21cm wide) at 300dpi takes about 2min and 45
> > Rainer> sec. If I scan at 100 dpi the effect is basically still
> > Rainer> there but the sanner then scans a larger area in one step
> > Rainer> before going back only a little. So the whole thing works
> > Rainer> faster.
> >
> > Rainer> What suprises me a lot, is that under windows doing the same
> > Rainer> scanprocess at the same resolution (via the mustec-twain
> > Rainer> driver) does not cause backtracking to occur and is
> > Rainer> completed much much faster (not even half the time).
> >
> > What size scan-buffer are you using? If you're using the default size
> > of 32KB, could you try increasing it to 127.5KB? See sane-scsi(5) for
> > info on how to do that.
> >
> > If increasing the scan buffer size to 127.5KB doesn't help, the
> > backtracking could be due to timing problems. If the scanner software
> > is too slow to issue the next "read data" command then backtracking
> > would occur. What kind of computer are you using and how much memory
> > does it have?
> >
> > --david
> >
>
> As I already told in my mail. The scanbuffer is 127K large (in Kernel
> and sane).Scanning works allrightfor me (the results are allright but
> not the scantime). My computer is a 90Mhz Pentium it has 48Mb RAM
> installed. So it cannot be the buttleneck. But I really think it's got
> to do with data xfer since it does not happen when scanning at a lower
> resolution or in Lineart mode where less data has to be xferred.
>
> Could it be that its because the scanner and the harddisk on which the
> data has to be stored is on the same controller (ADAPTEC 2940) like the
> scanner so that there is a problem.
What I think that is causing the bottleneck is that Linux has a layered
approach. This means that the kernel has a buffer, which has to be copied
over to userspace. This copy takes long enough for the scanner to decide
that backtracking is neccesary.
> By the way I really do not understand why backtracking is needed after
> all, cause I don't know whats really happening. Can someone give me a
> pointer to information on this ?
If you stop, and start again, the first few lines might be scanned
at a slightly different position. 1 pixel is only 1/300th of an inch.
1 600th of an inch positional difference is already clearly visible.
Therefore you need a "running start" at higher resolutions.
Roger.
--
Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/
To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com