Hello Bernd,
On Fri, 31 Dec 1999 12:47:23 Bernd Schroeder wrote:
> Basically, what the backend does, when backend calibration is
enabled, is to
> read some lines of image data at maximum resolution from a white
stripe that
> is located ahead of the actual scan area. It reads these lines twice,
the
> first time with the lamp turned on, and a second time with the lamp
turned
> off. The result are 2 x 5100 colour values, which - simply said -
represent
> what the device's impression of white resp. black is for each pixel
in a
> line.
Under Windows, there is maybe only 1 calibration pass (with lamp
on?), as the noise before the scan is shorter and slightly
different from that under SANE (IIRC).
> If you count the number of bits in the response block of 'read
control bits',
> that are 1's, you will see that there are as many 1's as the image
has
> pixels per line. What is necessary is to apply a shading correction
> function to each pixel of the scanned image, and the 1's in 'read
> control bits' serve as an index into the shading data. For example,
if the
> the first 1 is at bit position 27, the 27th byte in the shading data
must
> be combined with the first pixel of image data, if the second 1 is at
> position 42 the 42th byte of shading data must be combined with the
> second byte of image data, etc.
>
> At present there are some problems:
>
> - The 'read control bits' is not documented in the documentation that
I have,
> but from what I have heard about this command the first 1 in 'read
control
> bits' could possibly start at position 1, and if a scan at maximum
> resolution is performed I would expect 5100 consecutive 1's
starting
> at the beginning of the output of 'read control bits'. However,
this
> is not the case, the first two bytes are always zero. Actually the
> latest version of the backend skips the first two bytes.
>
> - The 1's are not consecutive. Again if you are scanning at maximum
> resolution the output of 'read control bits' starts with
0000ffcfffff..
> and ends similar to ...ffff3f000000 (IIRC). These small gaps with
> non-consecutive 1's cause the backend to read beyond position 5100
> of the shading data, which is probably the reason why the
application
> crashes, but at the moment I don't know how to handle these gaps.
>
> - I don't know how exactly the shading correction function looks. The
> documentation defines quite a bunch of them, but the function
needed
> for the 636cx is none of them.
>
I don't know nothing of either, unfortunately. And do you know
what the smdcr.9ar file is for in the "microtek\dcr" directory
under Windows? According to the on-line help, there is a generic
color calibration profile even for the models like mine which can
not be calibrated by hand. I suspect this file being the generic
profile, as the extension is "9ar" could mean "model 0x9a
reflective media". I do not know if this profile is read each
time I scan with the Twain driver, but removing it from its
directory prevent scanning. I dont't know however how the Windows
driver can send this profile to the scanner, as my model does not
seem to allow custom profiles. Could these profiles be used with
SANE?
Concerning the "vertical stripes" and the "dark and uneven
background" problems I wrote about, I played around a little bit
with different image settings. When I scan an image with SANE,
the histogram of a typical image is as below:
XXX XXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X
the image is dark, the background is uneven and there are fine
vertical stripes. When I play with the shadow/higlight/midtone
settings to exclude the rightmost histogram peak, the stripes are
much fainter, the image better, almost as good as scanned under
Windows. However the enhanced image's histogram is still
different of that of scanned under Windows. What can be the cause
of this improved look if a part of the histogram is excluded from
the image?
Finally, I discovered that while mirroring is solved for the
scanned image and the previews, there is a little problem
remaining: if the area to scan is at the upper left part of the
scanner's window, I have to mark the upper right part to have the
desired area scanned! So the selected area in xsane or xscanimage
is still mirrored while the image itself is not anymore. I
suppose the upper-left and lower-right coordinates which delimit
this area are not recalculated by the backend while the image and
the preview are mirrored.
Thank you for your work. If you want me to test something, I will
do it with pleasure.
Levente
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sat Jan 08 2000 - 17:52:23 PST