[sane-devel] continuous capture from scanner

Kyle McDonald mcdonk at rpi.edu
Thu Apr 2 03:29:00 UTC 2009

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:


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 

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


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

More information about the sane-devel mailing list