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 <mcdonk at rpi.edu> 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 at 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 at lists.alioth.debian.org > -- "The truth is an offense, but not a sin"