kopia lustrzana https://gitlab.com/sane-project/website
91 wiersze
4.7 KiB
HTML
91 wiersze
4.7 KiB
HTML
<!-- received="Fri Apr 3 11:28:02 1998 PST" -->
|
|
<!-- sent="Fri, 3 Apr 1998 14:27:22 -0500 (EST)" -->
|
|
<!-- name="Matto Marjanovic" -->
|
|
<!-- email="maddog@mir.com" -->
|
|
<!-- subject="Re: Artec AT3 and A6000C Plus driver" -->
|
|
<!-- id="m0yLC7W-000J1uC@yoo-hoo.ai.mit.edu" -->
|
|
<!-- inreplyto="Artec AT3 and A6000C Plus driver" -->
|
|
<title>sane-devel: Re: Artec AT3 and A6000C Plus driver</title>
|
|
<h1>Re: Artec AT3 and A6000C Plus driver</h1>
|
|
<b>Matto Marjanovic</b> (<a href="mailto:maddog@mir.com"><i>maddog@mir.com</i></a>)<br>
|
|
<i>Fri, 3 Apr 1998 14:27:22 -0500 (EST)</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#40">[ date ]</a><a href="index.html#40">[ thread ]</a><a href="subject.html#40">[ subject ]</a><a href="author.html#40">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0041.html">Matto Marjanovic: "Re: Linux Sense buffer (was: sane 0.71 and microtek E3)"</a>
|
|
<li> <b>Previous message:</b> <a href="0039.html">Jorgen Pehrson: "Olympys & Sane?"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
From: Chris Pinkham <<a href="mailto:cpinkham@billing.infi.net">cpinkham@billing.infi.net</a>><br>
|
|
<p>
|
|
Rogier Wolff wrote:<br>
|
|
<i> > Chris Pinkham wrote:</i><br>
|
|
<i> > > week or so. I have the driver working for greyscale and am finishing up</i><br>
|
|
<i> > > correcting a RGB-mode line-offset problem similar to the Microtek. </i><br>
|
|
<p>
|
|
<i> > Would it be a good idea to make a sort of "library" that can solve the</i><br>
|
|
<i> > line-offset problems, given a few parameters passed by the backend?</i><br>
|
|
<p>
|
|
I was going to break the code to correct this out into it's own function<br>
|
|
anyway, maybe this could be done later. I haven't looked at the Microtek<br>
|
|
code that closely, but I see that it also has code to convert a line of<br>
|
|
the form 'RRRRGGGGBBBB' into 'RGBRGBRGBRGB', so it might be good to move<br>
|
|
<p>
|
|
Yep, it does --- and it's some of the ugliest code I've ever written (I do<br>
|
|
plan to clean it up, etc, etc).<br>
|
|
<p>
|
|
The Microtek docs specify a couple of possible color image encodings; the<br>
|
|
one that seems prevalent on the one-pass scanners is "Non-sequential RGB"<br>
|
|
or something like that. Each line from the scanner is either the R, G, or<br>
|
|
B values, not necessarily in any order --- but the first two bytes contain<br>
|
|
a tag which identifies which of R, G, or B that line is supposed to be.<br>
|
|
During the typical scan, there are extra R's at the beginning, until G and<br>
|
|
then B catch up, then pretty much RGB, then extra G's, and extra B's at the<br>
|
|
end, like on the Artec scanner. There is also a relation between the<br>
|
|
vert. resolution and the delay, which empirically involves the magic<br>
|
|
number "37".<br>
|
|
The backend doesn't count on "37", though, but just uses it as a heuristic<br>
|
|
for creating buffers to hold the extra lines and to hold overflow. During<br>
|
|
a scan, the backend puts each byte of each color band into the proper place<br>
|
|
in the return buffer and only returns lines when they have all three colors;<br>
|
|
it tries to only copy bytes from SCSI buffer to frontend buffer once, if<br>
|
|
possible.<br>
|
|
Incomplete lines are buffered between calls to sane_read, so that the fill<br>
|
|
can continue on the next call. If I ever get around to implementing a <br>
|
|
whizzy non-blocking mode with a forked process, I could probably use a <br>
|
|
ring buffer to get around this and do *no* excess copying whatsoever.<br>
|
|
<p>
|
|
...<br>
|
|
of Green. The actual scan window has to be set to the desired size +<br>
|
|
(offset * 2) because we throw away (offset) lines at the beginning<br>
|
|
and end of the scan. I'm going to make a function where I pass it a<br>
|
|
...<br>
|
|
<p>
|
|
Hmm... the Microtek backend doesn't throw anything away: every byte from<br>
|
|
the scanner ends up in the image (except for those tag bytes).<br>
|
|
<p>
|
|
It might be difficult to extract this code out into a common offset-scan<br>
|
|
library, because of the tag bytes, et al. There is also stuff in the<br>
|
|
Microtek backend to do horizontal rescaling to handle "extended resolutions"<br>
|
|
properly (i.e. that 1200x1200, which is really 600x1200 optical).<br>
|
|
<p>
|
|
-matt m.<br>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
|
</pre>
|
|
<!-- body="end" -->
|
|
<p>
|
|
<ul>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0041.html">Matto Marjanovic: "Re: Linux Sense buffer (was: sane 0.71 and microtek E3)"</a>
|
|
<li> <b>Previous message:</b> <a href="0039.html">Jorgen Pehrson: "Olympys & Sane?"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|