On Wed, 6 Oct 2004 23:19:27 +0200, Henning Meier-Geinitz <henn...@meier-geinitz.de> wrote: > Hi, > > 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. >
Thanks for the input thus far - I have some new results/information I did some remote scanning tests with the scanner hooked up to a mandrake10 box (2.6.xx kernel). The delay in starting to scan was not as intrusive as it is on the RH7.3 box (2.4.18 kernel). In fact - it was able to scan at 1200 DPI, whereas when using the RH7.3 box it just would timeout I upped the memory in the RH box - and still the same result. SO now there are three main differences with the MDK and RH box - the kernel and the CPU: 1 - the RH box has 1.0.14 and the MDK box 1.0.13 2 - the kernel - 2.4 uses scanner.o and 2.6 uses libusb 3 - the RH box is a 500Mhz and the MDK box is an 800 would any of these be a direct reason for the delay in starting the scan? I understand that there are 3 variables - but if libusb is the main key - that would be good to know I am going to try to revert to 1.0.13 and see what happens I can then try rolling out a more CPU equivalent box so the real variable is the LIBUSB - does anyone know if that is a module in 2.4.xx? thanks > 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. > > Bye, > Henning > > > > -- > sane-devel mailing list: sane-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Unsubscribe: Send mail with subject "unsubscribe your_password" > to sane-devel-requ...@lists.alioth.debian.org >
