[sane-devel] Reflecta ProScan 7200

Vleeshouwers, J.M. J.M.Vleeshouwers at tue.nl
Thu Apr 28 19:37:20 UTC 2011

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?



More information about the sane-devel mailing list