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 <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 >> > > >
