Rogier Wolff wrote:
> Chris Pinkham wrote:
> > week or so. I have the driver working for greyscale and am finishing up
> > correcting a RGB-mode line-offset problem similar to the Microtek.
> Would it be a good idea to make a sort of "library" that can solve the
> line-offset problems, given a few parameters passed by the backend?
I was going to break the code to correct this out into it's own function
anyway, maybe this could be done later. I haven't looked at the Microtek
code that closely, but I see that it also has code to convert a line of
the form 'RRRRGGGGBBBB' into 'RGBRGBRGBRGB', so it might be good to move
Yep, it does --- and it's some of the ugliest code I've ever written (I do
plan to clean it up, etc, etc).
The Microtek docs specify a couple of possible color image encodings; the
one that seems prevalent on the one-pass scanners is "Non-sequential RGB"
or something like that. Each line from the scanner is either the R, G, or
B values, not necessarily in any order --- but the first two bytes contain
a tag which identifies which of R, G, or B that line is supposed to be.
During the typical scan, there are extra R's at the beginning, until G and
then B catch up, then pretty much RGB, then extra G's, and extra B's at the
end, like on the Artec scanner. There is also a relation between the
vert. resolution and the delay, which empirically involves the magic
number "37".
The backend doesn't count on "37", though, but just uses it as a heuristic
for creating buffers to hold the extra lines and to hold overflow. During
a scan, the backend puts each byte of each color band into the proper place
in the return buffer and only returns lines when they have all three colors;
it tries to only copy bytes from SCSI buffer to frontend buffer once, if
possible.
Incomplete lines are buffered between calls to sane_read, so that the fill
can continue on the next call. If I ever get around to implementing a
whizzy non-blocking mode with a forked process, I could probably use a
ring buffer to get around this and do *no* excess copying whatsoever.
...
of Green. The actual scan window has to be set to the desired size +
(offset * 2) because we throw away (offset) lines at the beginning
and end of the scan. I'm going to make a function where I pass it a
...
Hmm... the Microtek backend doesn't throw anything away: every byte from
the scanner ends up in the image (except for those tag bytes).
It might be difficult to extract this code out into a common offset-scan
library, because of the tag bytes, et al. There is also stuff in the
Microtek backend to do horizontal rescaling to handle "extended resolutions"
properly (i.e. that 1200x1200, which is really 600x1200 optical).
-matt m.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com