# Re: microtek ScanMaker X6 (EL)

Bernd Schroeder (bernd@aquila.muc.de)
Fri, 12 Mar 1999 13:09:55 +0100

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Jamie Zawinski: "xscanimage won't detect my scanner"
- Previous message: Petter Reinholdtsen: "SnapScan 1236 fails 'scanimage -T'"

On Tue, Mar 09, 1999 at 11:17:27PM -0500, wwc@wwcnet.nu wrote:
>
> Hi,
> After further testing, the problem is only with the new version,
> not in the 0.5 version. I'm attaching a gzip'ed file of a debug output
> (only 6k) which shows 2 scans, first is good, second is bad.

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

     Next message: Jamie Zawinski: "xscanimage won't detect my scanner"
     Previous message: Petter Reinholdtsen: "SnapScan 1236 fails 'scanimage -T'"