kopia lustrzana https://gitlab.com/sane-project/website
280 wiersze
9.0 KiB
HTML
280 wiersze
9.0 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>sane-devel: Re: Phantom 636cx and microtek2</TITLE>
|
|
<META NAME="Author" CONTENT="Levente NOVÁK (novak@jaguar.dote.hu)">
|
|
<META NAME="Subject" CONTENT="Re: Phantom 636cx and microtek2">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: Phantom 636cx and microtek2</H1>
|
|
<!-- received="Sat Jan 1 08:17:49 2000" -->
|
|
<!-- isoreceived="20000101161749" -->
|
|
<!-- sent="Sat, 1 Jan 2000 16:27:39 +0100" -->
|
|
<!-- isosent="20000101152739" -->
|
|
<!-- name="Levente NOVÁK" -->
|
|
<!-- email="novak@jaguar.dote.hu" -->
|
|
<!-- subject="Re: Phantom 636cx and microtek2" -->
|
|
<!-- id="947382743.0000@hypermail.dummy" -->
|
|
<!-- inreplyto="Phantom 636cx and microtek2" -->
|
|
<STRONG>From:</STRONG> Levente NOVÁK (<A HREF="mailto:novak@jaguar.dote.hu?Subject=Re:%20Phantom%20636cx%20and%20microtek2&In-Reply-To=<947382743.0000@hypermail.dummy>"><EM>novak@jaguar.dote.hu</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Sat Jan 01 2000 - 07:27:39 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<UL>
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0002.html">Andreas Muck: "Re: UMAX Astra 600S and SCSI disks on the same adapter"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0000.html">Oliver Rauch: "Re: UMAX Astra 600S and SCSI disks on the same adapter"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0015.html">Levente NOVAK: "Re: Phantom 636cx and microtek2"</A>
|
|
<LI><STRONG>Maybe reply:</STRONG> <A HREF="0015.html">Levente NOVAK: "Re: Phantom 636cx and microtek2"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#1">[ date ]</A>
|
|
<A HREF="index.html#1">[ thread ]</A>
|
|
<A HREF="subject.html#1">[ subject ]</A>
|
|
<A HREF="author.html#1">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Hello Bernd,
|
|
<BR>
|
|
<P>On Fri, 31 Dec 1999 12:47:23 Bernd Schroeder wrote:
|
|
<BR>
|
|
<P><EM>> Basically, what the backend does, when backend calibration is
|
|
</EM><BR>
|
|
enabled, is to
|
|
<BR>
|
|
<EM>> read some lines of image data at maximum resolution from a white
|
|
</EM><BR>
|
|
stripe that
|
|
<BR>
|
|
<EM>> is located ahead of the actual scan area. It reads these lines twice,
|
|
</EM><BR>
|
|
the
|
|
<BR>
|
|
<EM>> first time with the lamp turned on, and a second time with the lamp
|
|
</EM><BR>
|
|
turned
|
|
<BR>
|
|
<EM>> off. The result are 2 x 5100 colour values, which - simply said -
|
|
</EM><BR>
|
|
represent
|
|
<BR>
|
|
<EM>> what the device's impression of white resp. black is for each pixel
|
|
</EM><BR>
|
|
in a
|
|
<BR>
|
|
<EM>> line.
|
|
</EM><BR>
|
|
<P>Under Windows, there is maybe only 1 calibration pass (with lamp
|
|
<BR>
|
|
on?), as the noise before the scan is shorter and slightly
|
|
<BR>
|
|
different from that under SANE (IIRC).
|
|
<BR>
|
|
|
|
<BR>
|
|
<EM>> If you count the number of bits in the response block of 'read
|
|
</EM><BR>
|
|
control bits',
|
|
<BR>
|
|
<EM>> that are 1's, you will see that there are as many 1's as the image
|
|
</EM><BR>
|
|
has
|
|
<BR>
|
|
<EM>> pixels per line. What is necessary is to apply a shading correction
|
|
</EM><BR>
|
|
<EM>> function to each pixel of the scanned image, and the 1's in 'read
|
|
</EM><BR>
|
|
<EM>> control bits' serve as an index into the shading data. For example,
|
|
</EM><BR>
|
|
if the
|
|
<BR>
|
|
<EM>> the first 1 is at bit position 27, the 27th byte in the shading data
|
|
</EM><BR>
|
|
must
|
|
<BR>
|
|
<EM>> be combined with the first pixel of image data, if the second 1 is at
|
|
</EM><BR>
|
|
<EM>> position 42 the 42th byte of shading data must be combined with the
|
|
</EM><BR>
|
|
<EM>> second byte of image data, etc.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> At present there are some problems:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> - The 'read control bits' is not documented in the documentation that
|
|
</EM><BR>
|
|
I have,
|
|
<BR>
|
|
<EM>> but from what I have heard about this command the first 1 in 'read
|
|
</EM><BR>
|
|
control
|
|
<BR>
|
|
<EM>> bits' could possibly start at position 1, and if a scan at maximum
|
|
</EM><BR>
|
|
<EM>> resolution is performed I would expect 5100 consecutive 1's
|
|
</EM><BR>
|
|
starting
|
|
<BR>
|
|
<EM>> at the beginning of the output of 'read control bits'. However,
|
|
</EM><BR>
|
|
this
|
|
<BR>
|
|
<EM>> is not the case, the first two bytes are always zero. Actually the
|
|
</EM><BR>
|
|
<EM>> latest version of the backend skips the first two bytes.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> - The 1's are not consecutive. Again if you are scanning at maximum
|
|
</EM><BR>
|
|
<EM>> resolution the output of 'read control bits' starts with
|
|
</EM><BR>
|
|
0000ffcfffff..
|
|
<BR>
|
|
<EM>> and ends similar to ...ffff3f000000 (IIRC). These small gaps with
|
|
</EM><BR>
|
|
<EM>> non-consecutive 1's cause the backend to read beyond position 5100
|
|
</EM><BR>
|
|
<EM>> of the shading data, which is probably the reason why the
|
|
</EM><BR>
|
|
application
|
|
<BR>
|
|
<EM>> crashes, but at the moment I don't know how to handle these gaps.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> - I don't know how exactly the shading correction function looks. The
|
|
</EM><BR>
|
|
<EM>> documentation defines quite a bunch of them, but the function
|
|
</EM><BR>
|
|
needed
|
|
<BR>
|
|
<EM>> for the 636cx is none of them.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<P>I don't know nothing of either, unfortunately. And do you know
|
|
<BR>
|
|
what the smdcr.9ar file is for in the "microtek\dcr" directory
|
|
<BR>
|
|
under Windows? According to the on-line help, there is a generic
|
|
<BR>
|
|
color calibration profile even for the models like mine which can
|
|
<BR>
|
|
not be calibrated by hand. I suspect this file being the generic
|
|
<BR>
|
|
profile, as the extension is "9ar" could mean "model 0x9a
|
|
<BR>
|
|
reflective media". I do not know if this profile is read each
|
|
<BR>
|
|
time I scan with the Twain driver, but removing it from its
|
|
<BR>
|
|
directory prevent scanning. I dont't know however how the Windows
|
|
<BR>
|
|
driver can send this profile to the scanner, as my model does not
|
|
<BR>
|
|
seem to allow custom profiles. Could these profiles be used with
|
|
<BR>
|
|
SANE?
|
|
<BR>
|
|
<P>Concerning the "vertical stripes" and the "dark and uneven
|
|
<BR>
|
|
background" problems I wrote about, I played around a little bit
|
|
<BR>
|
|
with different image settings. When I scan an image with SANE,
|
|
<BR>
|
|
the histogram of a typical image is as below:
|
|
<BR>
|
|
<P> XXX XXXXXXXXXX
|
|
<BR>
|
|
XXXXXXXXXXXXXXXXXXXXXXXXX
|
|
<BR>
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXX
|
|
<BR>
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
<BR>
|
|
XXXXXXXXX
|
|
<BR>
|
|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
<BR>
|
|
X
|
|
<BR>
|
|
<P>the image is dark, the background is uneven and there are fine
|
|
<BR>
|
|
vertical stripes. When I play with the shadow/higlight/midtone
|
|
<BR>
|
|
settings to exclude the rightmost histogram peak, the stripes are
|
|
<BR>
|
|
much fainter, the image better, almost as good as scanned under
|
|
<BR>
|
|
Windows. However the enhanced image's histogram is still
|
|
<BR>
|
|
different of that of scanned under Windows. What can be the cause
|
|
<BR>
|
|
of this improved look if a part of the histogram is excluded from
|
|
<BR>
|
|
the image?
|
|
<BR>
|
|
<P>Finally, I discovered that while mirroring is solved for the
|
|
<BR>
|
|
scanned image and the previews, there is a little problem
|
|
<BR>
|
|
remaining: if the area to scan is at the upper left part of the
|
|
<BR>
|
|
scanner's window, I have to mark the upper right part to have the
|
|
<BR>
|
|
desired area scanned! So the selected area in xsane or xscanimage
|
|
<BR>
|
|
is still mirrored while the image itself is not anymore. I
|
|
<BR>
|
|
suppose the upper-left and lower-right coordinates which delimit
|
|
<BR>
|
|
this area are not recalculated by the backend while the image and
|
|
<BR>
|
|
the preview are mirrored.
|
|
<BR>
|
|
<P>Thank you for your work. If you want me to test something, I will
|
|
<BR>
|
|
do it with pleasure.
|
|
<BR>
|
|
<P>Levente
|
|
<BR>
|
|
<P><P><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?Subject=Re:%20Phantom%20636cx%20and%20microtek2&In-Reply-To=<947382743.0000@hypermail.dummy>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0002.html">Andreas Muck: "Re: UMAX Astra 600S and SCSI disks on the same adapter"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0000.html">Oliver Rauch: "Re: UMAX Astra 600S and SCSI disks on the same adapter"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0015.html">Levente NOVAK: "Re: Phantom 636cx and microtek2"</A>
|
|
<LI><STRONG>Maybe reply:</STRONG> <A HREF="0015.html">Levente NOVAK: "Re: Phantom 636cx and microtek2"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#1">[ date ]</A>
|
|
<A HREF="index.html#1">[ thread ]</A>
|
|
<A HREF="subject.html#1">[ subject ]</A>
|
|
<A HREF="author.html#1">[ author ]</A>
|
|
</UL>
|
|
<!-- trailer="footer" -->
|
|
<HR NOSHADE>
|
|
<P>
|
|
<SMALL>
|
|
<EM>
|
|
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
|
: <EM>Sat Jan 08 2000 - 17:52:23 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|