[sane-devel] Reflecta ProScan 7200

[Vleeshouwers, J.M.]

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