I understand the CCD/CIS distinction -- I wasn't planning on moving the light adjacent to the scan head, just thinking about what sort of extra lighting might be necessary.
I found some older models of the Corex Cardscan that seem pretty cheap and hackable, but I can't find the 800 model. Is the EOF reported by the firmware once it has completed scanning the region specified, or is it handled at the software level? Also, I found this old conversation: http://lists.alioth.debian.org/pipermail/sane-devel/2003-March/007252.html Which looks pretty similar, but I can't tell if it ever worked out or not. I am looking for something similar: real-time scanning with a fixed y-position. When you refer say "run even if not calibrated", are you referring to a calibration step handled by the firmware in between captures? Looking through the old archives, it looks like most scanners take this calibration step using their white background as a white point... but does it necessarily happen between captures/image acquisitions, or just between sessions/device setups? If this happens between captures it sounds like this would be the biggest timing glitch. Mentioned in the old conversation was the possibility of using a webcam. It's an easy solution, but requires a good bit of depth/distance from the interaction (you can't sit it on a table) and is limited by framerate (30-60 fps). I've spent a lot of time experimenting with webcams, and would like to try scanners a bit :) Kyle 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 <mcdonk at rpi.edu> 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 <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 >>>> >>> >>> >> -- >> 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 >> > > >