Frederik Ramm wrote:
>
> Question 1 - How to do duplex scanning.
>
> To use the duplex mode, I have to send an extended SET WINDOW command
> to the scanner which should be no problem. The question is, how do I
> then feed the two images into SANE? As far as I can see from the
> existing driver, a subprocess gets started to read more-or-less raw
> binary data from the scanner, which is then passed via a pipe to the
> calling program; it seems to "leave" the backend via the sane_read
> function. Since the scanner has dual scan heads and only 128 kB of
> cache, in duplex mode it will send a data stream that contains two
> interspersed images. I would be able to separate them on reading, but
> what next? How do I tell the SANE middleware (or front-end for that
> matter) that I actually have TWO images? How would a front-end (like
> scanimage, the only one I've used so far) cope?
>
It is no problem with SANE. xscanimage and xsane and I guess alos scanadf
do call sane_open at program start and sane_close at program exit.
When the frist sane_start is called you scan both images and send back
one image. When the next sane_start is called you send back the second image.
I think scanimage is not able to handle that but that is not a problem
of the SANE standard.
> Question 2 - How to do the color thing.
>
> This is just a quick question in case somebody has noticed something
> similar with their scanners. When I read color data from the scanner,
> I get one row of "R" values, then one row of "G" values, then one row
> of "B" values, and so on. These are slightly offset, e.g. the first
> row of "R" values have to be paired with the fifth row of "G" and the
> ninth row of "B" values or so (the documentation is detailed but at
> the same time not very clear on that - http://www.fujitsu-europe.com/
> home/support/scanner/manuals/M3091dc.scsi.en.pdf, pp. 75-77). So far,
> so good, but in reality it seems that after a certain number of these
> R row/G row/B row groups I suddenly get TWO R rows following each
> other, and then on like before, and the same phenomenon again every x
> blocks. I haven't fully investigated that and don't really know what
> to make of it yet.
Some UMAX scanners also do send back the images this way.
Take a look at the routines in umax.c:
umax_order_line
umax_order_line_to_pixel
umax_forget_line
There still seems to be a little bug in this routines
because at special resolutions it does not work correct,
but in most cases it does work.
Bye
Oliver
-- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:Oliver.Rauch@rauch-domain.de-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Tue Feb 27 2001 - 10:54:54 PST