Hi again, It's been a few months, but I've come back to this. I received some Visioneer XP 100s from Jack Hill, and have been experimenting with them for the past few days, I have two questions, but first a quick note about where I am so far. I came across quite a few stumbling blocks (maybe just because I'm used to Windows, not Linux), but I finally got things working like this: - - -- 0 Fresh install of Ubuntu 9.04 1 Uninstall all sane-related packages via Synaptic package manager 2 Install latest libusb-dev via Synaptic 3 Download latest SANE source, extract to ~/sane-backends, then: $cd ~/sane-backends $./configure --prefix=/usr --sysconfdir=/etc $make $sudo make install 4 $sane-find-scanner returns: found USB scanner (vendor=0x04a7, product=0x0427, chip=LM983x?) at libusb:005:002 5 $scanimage -L doesn't work, but $sudo scanimage -L does 6 Machine gun permissions $sudo chmod a+w /dev/bus/usb/* 7 Write C++ using the SANE API, compiled and linked against sane.h and -lsane - - -- Right now I have an app running that visualizes the input from the scanner in real time. At 50 dpi I get ~30 lines/sec, at 1200 dpi ~60 lines/sec. q1: Why are the lines returned in "chunks"? By this I mean sane_read will block for so many milliseconds, and then the next ~1-32 calls to sane_read will all return seemingly instantaneously. I tried going into non-blocking mode, but the &size that is passed as the final argument to sane_read seems to exhibit the same behavior: it doesn't "fill up" for a while, and then all of a sudden it fills up multiple lines. Right now I'm dealing with this by buffering 32 lines, and limiting the rate at which I read from the buffer. This isn't ideal, as it introduces some latency, but it works. q2: Is there any way to force the scanner to stay in the sane_read loop? It was mentioned that some models don't have any notion of "paper length", but this one definitely does. One of the geometry options is "y", which ranges from 0 to 297mm. There is a (relatively) long pause between consecutive pairs of sane_start/sane_read/sane_cancel blocks, and I'd like to avoid that if possible. I'm aware I'm trying to use SANE in an unusual way (real time input), but I'd really appreciate any tips! Thanks! Kyle ==============Original message text=============== On Wed, 01 Apr 2009 20:17:03 EDT "m. allan noah" wrote: sounds like a solution looking for a problem :) Try searching the mailing list archives for 'music' - this idea comes up occasionally. read up on CIS vs CCD machines before you decide to mess with the light source. I would also suggest you expand your search to include ADF machines. It is only 4 inches wide, but the Corex Cardscan 800 has no concept of paper length at all. you just say 'read X rows', with the lamp on or off and with the feed motor on or off. so you could either read 1 or 2 rows repeatedly to get a more consistent time signature, or read 16 or so lines and deal with the stutter. Some of the cheaper canon DR series machines also seem to run even if not calibrated, but they've got paper sensors that would have to be fooled. allan On Wed, Apr 1, 2009 at 6:35 PM, Kyle McDonald wrote: > Hey Allan + everyone, > > I had a scanner, but I took it apart to understand it at a hardware > level... I took it too far (to the point of needing to generate clock > signals for the scan head, etc.) I'd much rather work at a software > level than reverse engineering the scan head. > > I would remove the read head in a way that the servos could still move, > but the read head wouldn't. Later I would probably short the feedback > mechanism so I could minimize the amount of external hardware necessary. > > There are two ideas I have in mind. If anyone gets the chance to > implement them first, let me know :) > > 1 Scanner spectroscopy: prism separates light onto a scan head for > cheap/DIY real-time spectroscopy of various substances/materials. > > 2 Linear multitouch: using the scan head to sense dark/light areas > (fingers, whatever). > > Size isn't essential -- any regular 8-inch-ish head would be great. > Color is also nonessential, but helpful. Bit depth... the regular 8-bits > per color is fine. Depth of field: shallow is better in both these > cases. I would experiment with the light source in case 2, I'd have to > empirically determine the best placement. > > The biggest requirement, really, is an unusual one: "framerate". If the > "scan a 1 pixel high region over and over" technique is used, the stall > time between captures determines the maximum framerate. If the "scan a > whole page without moving the scan head" technique is used, we're > talking hundreds/thousands of fps (minus the glitch at the page/capture > boundary). > > Kyle > > m. allan noah wrote: >> sane is not the problem, but rather, which scanner? many of them >> produce ugly scans if they are not calibrated, and many of them have >> the red/green/blue read-heads offset from one another so that they >> cannot produce a scan of a single line. many of them will choke if >> they cannot move the read head. >> >> Perhaps if you could be more specific as to your needs, we could help >> you better. things like: width, color/gray, bit depth, depth of field, >> will you keep the light source, etc. >> >> allan >> >> On Wed, Apr 1, 2009 at 5:32 PM, Kyle McDonald wrote: >>> I'd like to use a flatbed scanner for continuous capture. By this I mean: >>> the scan head does not move, and I regularly (quickly) get updates from >>> the scan head. >>> >>> If I understand SANE, there are at least two ways I might do this: >>> >>> 1 Physically modify the scanner to not move the head, and capture images >>> that are the maximum dimension of the scan area. Use sane_read to >>> continually update the scan head state, which is accessed by another thread. >>> >>> 2 Capture images that are one pixel tall. >>> >>> Both of these require using sane_start to get a new frame every so often >>> (much more often, in the case of 2), and I'm worried about the "glitch" >>> that will occur at that point. Does anybody have an idea about how long >>> the scanner will stall while getting ready to start a new frame? It's >>> probably very scanner-dependent, I'm guessing... but on order of >>> magnitude guess would be great. Or: is there a way to continue using >>> sane_read without worrying about approaching an EOF...? >>> >>> Thanks! >>> Kyle >>> >>> >>> >>> -- >>> 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-request@lists.alioth.debian.org >>> >> >> >> > > -- > 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-request@lists.alioth.debian.org > -- "The truth is an offense, but not a sin" ===========End of original message text===========