[sane-devel] Re: strange problems LIDE30

Henning Meier-Geinitz henning@meier-geinitz.de
Wed, 6 Oct 2004 23:19:27 +0200


On Wed, Oct 06, 2004 at 05:07:46PM -0400, Brian K. White wrote:
> The manufacturer says that it does 1200x2400 optically, but xsane only 
> offers a listbox that says a single value from 0 to 2400, no XXXxYYY 
> choices, so I picked 2400 just to go for a worst case scenario but I have 
> no idea what it's actually going to do.
> A lie, only actualy produce 1200x1200? a distorted image? silently double 
> every pixel in one direction? silently double every pixel in both 
> directions? or maybe the scanner will do the doubling in one direction in 
> firmware and present sane with 2400x2400 data?

As it doesn't make sense to crete distorted images SANE backends
usually either duplicate pixels or interpolate them.

I've seen several Windows drivers that interpolate even if it's not
necessary: E.g. harware resolution 100 and 200 dpi, driver uses 100
dpi when asked for 200.

Also some scanners are advertized to make 600x1200 dpi but can't do
(and don't do) 1200 dpi even vertically. It looks like nobody ever
checked what the Windows driver really scans.

I don't know what's the case with the LiDEs, however.

> It's only at about 10 or 15% progress after 20 minutes so I'll send another 
> post when it's done, or when it crashes.

At least with the scanners supported by the gt68xx backend, a low scan
width is important for higher speed at high resolutions. As you
usually use high resolutions for smaller sections of photos or slides
that's not that unreasonable.

> This box has a gig of ram so hopefully it's enough for this worst-case 
> scenario if sane doesn't open a file and work with smaller chunks in ram. 
> This is a dual 1gig p3 too. That might be relevant by making it more likely 
> that there is always a cpu available to service the usb interrups? Or 
> rather, that the one cpu that seems to be the only one that even sees 
> interrupts, is more likely to be able to keep up.

One of the problems is that libusb doesn't allow async i/o. So you
can't send some buffers to be filled and wait for their completion.