I have uploaded a new pre0.6 version to
ftp://ftp.muc.de/people/bernds/mtek2/microtek2-pre0.6.120399.tar.gz .
This version should fix the problem with the random noise after
one successful color scan for all FW-releases of devices, that are
currently available.
However, I don't know yet, whether it solves the problem with the wrong
colors. I have reverted some changes since the 0.5 release, which
apparently worked better.
If it doesn't help, there is one more thing, that you or someone else
who experiences this problem, could test (I can't do that myself, because
I don't have such a device).
The following lines are from the trace output, the first line from a
scan with good results and the second line from a scan with wrong
colors (bpl is bytes per line and ppl mens pixels per line):
[microtek2] chunky_proc_data: lines=5, bpl=5502, ppl=1832, bpp=1, depth=8 junk=6
[microtek2] chunky_proc_data: lines=5, bpl=5772, ppl=1923, bpp=1, depth=8 junk=2
The spec defines several data formats how the image data can be transferred
from the device. For the format that is used by the X6EL and some other
models bpl should equal 3*ppl if the number of bytes per scanline is
even and 3*ppl+1 if the settings imply an odd number of pixels per line,
because a scanline is always aligned to a two byte boundary with a trailing
byte that must be ignored, if there is an odd number of pixels per line.
The trace output shows that this is not the case. There are more bytes
per line (indicated by junk= ) than expected. The backend ignores the
first junk=n bytes of a scanline. In the second case it ignores the
first two bytes of a line and the last byte, because the number of pixels
per line is odd.
The function in microtek2.c that copies the data from the SCSI buffer into
the buffer of the frontend is chunky_proc_data() and there is a line in it:
bpl_ppl_diff = ms->bpl - ( 3 * ms->ppl * bpp ) - pad;
bpl_ppl_diff is the number of bytes, that is ignored at the beginning of a
line. Maybe that the backend copies from the wrong position, because
ignoring the first junk=n bytes of a line is only a guess (that seemed to
work in the the 0.5 release, though). If someone can try it with different
values for bpl_ppl_diff and tell me the results, this would be helpful
(for example omit the "- pad" above, then the first three bytes of a line
are ignored). But I am not sure if this helps, because the backend should
copy from the same position of each line in the 0.5 and pre0.6 release.
Bernd
-- Bernd Schroeder Email: mailto:bernd@aquila.muc.de PGP public key available: mailto:pgp@aquila.muc.de | Subject: send key
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com