kopia lustrzana https://gitlab.com/sane-project/website
102 wiersze
4.9 KiB
HTML
102 wiersze
4.9 KiB
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>> </i><br>
|
|||
|
|
<i>> Hi,</i><br>
|
|||
|
|
<i>> After further testing, the problem is only with the new version,</i><br>
|
|||
|
|
<i>> not in the 0.5 version. I'm attaching a gzip'ed file of a debug output</i><br>
|
|||
|
|
<i>> (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->bpl - ( 3 * ms->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>
|