Hi Michael,
A last update with:
- GEM (grain equalisation) settings;
- a set of default scans with very different slides;
- a set with various crop settings.
Nothing spectacular. GEM is done in software completely. Default scans with
different slides (and a scan without slide)
do not appear to have much effect on the data transfered. I suspected the
11-byte DD-response to contain information
about the presence of a slide, but I was wrong. Requesting partial scans
results in different values sent to the
scanner in SET_SCAN_FRAME (SCSI 0a-12), and corresponding variations in the
data read by PARAM (SCSI 0f), as might be
expected. See http://www.stadspartijeindhoven.nl/jv/SettingsAnalysis.ods for
the details.
I think I have pretty much looked at all aspects the Windows-driver and
Cyberview have to offer. Did I miss anything?
I have not extracted photographic data from all snoops, but the ones I've seen
are all dark to very dark, some use no more
than 20% of the available range. Even if the scanner will not accept
GAMMA-settings (the pie.c-way or in another way),
we should still be able to use the scanner's output range better than this.
With respect to the "quality" setting: you're right, it's MODE_SELECT byte 9,
("required speed"), not 7.
I never quite listened to the sound the scanner makes, but it makes sense that
a larger exposure time results in a lower
scanner tone, since the stepper motor steps in a slower pace. It should also be
related to a lower gain setting, since
the CCD receives more light.
The details remain to be uncovered. I wonder why the scanner would have any
need for a "quality" bit at all, if
exposure time, gain and offset can be set elsewhere and in more detail. I also
wonder why there is some seemingly
random variation in byte 0&1 of the DC-output (red_texp), for example in the
default-runs (names with _df): these all
started with switching on the scanner and setting all options off. (And these
are not the only questions...)
Apart from the calibration data (1+13+31 lines) there is also the COPY input
(SCSI 18) which has not had any attention
yet. What could be the use of sending 1 byte of information for each CCD-pixel,
with no more variation than 0x70 or 0x00?
I would like to experiment a bit further. You offered to help me get the SANE
backend compiled from source, and from
what I read on the internet, that would help me a lot. The alternative would be
to build a very lightweight libusb-based
program to access the scanner directly. Is there anything this would allow me
to do which would not be
possible (or more difficult) in SANE?
Yours,
Jan
