sane-project-website/old-archive/1999-03/0119.html

<!-- received="Fri Mar 12 04:10:45 1999 PST" -->
<!-- sent="Fri, 12 Mar 1999 13:09:55 +0100" -->
<!-- name="Bernd Schroeder" -->
<!-- email="bernd@aquila.muc.de" -->
<!-- subject="Re: microtek ScanMaker X6 (EL)" -->
<!-- id="" -->
<!-- inreplyto="Pine.LNX.4.04.9903092314500.1322-101000@jerrold.wwcnet.nu" -->
<title>sane-devel: Re: microtek ScanMaker X6 (EL)</title>
<h1>Re: microtek ScanMaker X6 (EL)</h1>
<b>Bernd Schroeder</b> (<a href="mailto:bernd@aquila.muc.de"><i>bernd@aquila.muc.de</i></a>)<br>
<i>Fri, 12 Mar 1999 13:09:55 +0100</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#119">[ date ]</a><a href="index.html#119">[ thread ]</a><a href="subject.html#119">[ subject ]</a><a href="author.html#119">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0120.html">Jamie Zawinski: "xscanimage won't detect my scanner"</a>
<li> <b>Previous message:</b> <a href="0118.html">Petter Reinholdtsen: "SnapScan 1236 fails 'scanimage -T'"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
On Tue, Mar 09, 1999 at 11:17:27PM -0500, <a href="mailto:wwc@wwcnet.nu">wwc@wwcnet.nu</a> wrote:<br>
<i>&gt; </i><br>
<i>&gt; Hi,</i><br>
<i>&gt; 	After further testing, the problem is only with the new version,</i><br>
<i>&gt; not in the 0.5 version.  I'm attaching a gzip'ed file of a debug output</i><br>
<i>&gt; (only 6k) which shows 2 scans, first is good, second is bad.</i><br>
<p>
I have uploaded a new pre0.6 version to<br>
<p>
 <a href="ftp://ftp.muc.de/people/bernds/mtek2/microtek2-pre0.6.120399.tar.gz">ftp://ftp.muc.de/people/bernds/mtek2/microtek2-pre0.6.120399.tar.gz</a> .<br>
<p>
This version should fix the problem with the random noise after<br>
one successful color scan for all FW-releases of devices, that are<br>
currently available.<br>
<p>
However, I don't know yet, whether it solves the problem with the wrong<br>
colors. I have reverted some changes since the 0.5 release, which<br>
apparently worked better.<br>
<p>
If it doesn't help, there is one more thing, that you or someone else<br>
who experiences this problem, could test (I can't do that myself, because<br>
I don't have such a device).<br>
<p>
The following lines are from the trace output, the first line from a <br>
scan with good results and the second line from a scan with wrong<br>
colors (bpl is bytes per line and ppl mens pixels per line):<br>
<p>
[microtek2] chunky_proc_data: lines=5, bpl=5502, ppl=1832, bpp=1, depth=8 junk=6<br>
<p>
[microtek2] chunky_proc_data: lines=5, bpl=5772, ppl=1923, bpp=1, depth=8 junk=2<br>
<p>
The spec defines several data formats how the image data can be transferred<br>
from the device. For the format that is used by the X6EL and some other<br>
models bpl should equal 3*ppl if the number of bytes per scanline is<br>
even and 3*ppl+1 if the settings imply an odd number of pixels per line,<br>
because a scanline is always aligned to a two byte boundary with a trailing<br>
byte that must be ignored, if there is an odd number of pixels per line.<br>
<p>
The trace output shows that this is not the case. There are more bytes<br>
per line (indicated by junk= ) than expected. The backend ignores the<br>
first junk=n bytes of a scanline. In the second case it ignores the<br>
first two bytes of a line and the last byte, because the number of pixels<br>
per line is odd.<br>
<p>
The function in microtek2.c that copies the data from the SCSI buffer into<br>
the buffer of the frontend is chunky_proc_data() and there is a line in it:<br>
<p>
    bpl_ppl_diff = ms-&gt;bpl - ( 3 * ms-&gt;ppl * bpp ) - pad;<br>
<p>
bpl_ppl_diff is the number of bytes, that is ignored at the beginning of a<br>
line. Maybe that the backend copies from the wrong position, because<br>
ignoring the first junk=n bytes of a line is only a guess (that seemed to<br>
work in the the 0.5 release, though). If someone can try it with different<br>
values for bpl_ppl_diff and tell me the results, this would be helpful<br>
(for example omit the "- pad" above, then the first three bytes of a line<br>
are ignored). But I am not sure if this helps, because the backend should<br>
copy from the same position of each line in the 0.5 and pre0.6 release.<br>
<p>
Bernd<br>
<p>
<pre>
-- 
Bernd Schroeder 
Email: <a href="mailto:bernd@aquila.muc.de">mailto:bernd@aquila.muc.de</a>
PGP public key available: <a href="mailto:pgp@aquila.muc.de">mailto:pgp@aquila.muc.de</a> | Subject: send key 
<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="0120.html">Jamie Zawinski: "xscanimage won't detect my scanner"</a>
<li> <b>Previous message:</b> <a href="0118.html">Petter Reinholdtsen: "SnapScan 1236 fails 'scanimage -T'"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>