[sane-devel] continuous capture from scanner

m. allan noah kitno455 at gmail.com
Thu Apr 2 00:17:03 UTC 2009


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
>



-- 
"The truth is an offense, but not a sin"



More information about the sane-devel mailing list