[sane-devel] Reflecta ProScan 7200
Michael Rickmann
mrickma at gwdg.de
Wed May 18 16:47:26 UTC 2011
Hi Jan,
now what I found.
Am 02.05.2011 22:46, schrieb Vleeshouwers, J.M.:
< huge snip >
When looking at your analysis I find real differences between your
(CrystalScan 7200, firmware end of 2010) and my (ProScan 7200, firmware
end of 2009) scanner. For MODE_SELECT byte 9 your scanner sends 0x00,
0x0a or 0x08. Mine sends 0x00, 0x02 or 0x08. I have assumed that bit 1
means quality and that bit 3 stands for "skip calibration". Then 0x0a
would skip calibration in quality mode. I think you have reported a
different behaviour. I have to strictly obey the stetting of bit 3 in
reading the calibration lines or omitting the read. Otherwise my scanner
would get stuck. Another difference I found is that exposure/gain
settings are lower for your scanner than for mine. Additionally,
exposure/gain settings for quality and normal mode lie closer together
for your scanner. I think that we will have to find a way to distinguish
our scanners. I found a log file from Silverfast in the Windows
application data directory which among other things contains
Supp. Scanner: < > <PF1800AFL> <37=0x25>
Supp. Scanner: < > <PowerLook 180> <37=0x25>
Supp. Scanner: < > <PF 1800> <34=0x22>
Supp. Scanner: < > <POWERSLIDE 3600> <43=0x2b>
Supp. Scanner: < > <PF 1800> <42=0x2a>
Supp. Scanner: < > <2700> <40=0x28>
Supp. Scanner: < > <3650_4000> <44=0x2c>
Supp. Scanner: < > <3650U> <46=0x2e>
Supp. Scanner: < > <MF Film Scanner> <37=0x25>
Supp. Scanner: < > <3600FilmScanner> <39=0x27>
Supp. Scanner: < > <PF3600> <39=0x27>
Supp. Scanner: < > <SmartScan 3600> <39=0x27>
Supp. Scanner: < > <FilmScan 3600> <39=0x27>
Supp. Scanner: < > <RXS 3600> <36=0x24>
Supp. Scanner: < > <MS Scanner> <47=0x2f>
Supp. Scanner: <PIE > <MF Scanner> <49=0x31>
Supp. Scanner: < > <SF Scanner> <48=0x30>
Supp. Scanner: < > <SF Film Scanner> <42=0x2a>
Supp. Scanner: <ProScan> <7200> <54=0x36>
Supp. Scanner: <PIE > <MS Scanner> <58=0x3a>
Found on SCSI: bus: 0 unit: 1
: type : 6
: addlen : 32
: vendor : ProScan
: product : 7200
: firmware: 1.70
: inquire :
0: 6 0 0 0 20 0 0 0 50 72 6f 53 63 61
6e 0 .... ...ProScan.
10: 37 32 30 30 0 0 0 0 0 0 0 0 0 0
0 0 7200............
20: 31 2e 37 30
36 1.706
Found on SCSI: bus: 0 unit: 2
: type : 6
: addlen : 32
: vendor : PIE
: product : SF Scanner
: firmware: 1.70
: inquire :
0: 6 0 0 0 20 0 0 0 50 49 45 20 20 20
20 20 .... ...PIE
10: 53 46 20 53 63 61 6e 6e 65 72 0 0 0 0
0 0 SF Scanner......
20: 31 2e 37 30
36 1.706
I can delete that file and the same is written again. But I am
absolutely sure that the inquiry answer over USB did not contain the
word ProScan. So the information must have been sent differently. My
best bet is byte 0x74 (first 0, just behind get_inquiry_trans_y2) of the
inquiry block. It is the only 0x36 which I receive in that block.
I have been thinking a lot about how we could calibrate the scanners.
The following is only for quality mode. When we read the calibration
lines and have to calibrate from them we have to know at which
calibration settings those lines were taken. So I looked for some
resemblance between the dc-write calibration and the preceding d7-read
calibration block. This is my guess:
typedef struct PIE_USB_Calibration_Read
{
unsigned char zero_1[54];
/* values describing internal calibration, interpretation mostly
guessed */
uint16_t i_red; /* red targeted illumination, may be zero */
uint16_t i_green; /* green targeted illumination, may be zero */
uint16_t i_blue; /* (blue) targeted illumination, always
present */
uint16_t t_red; /* red exposure time */
uint16_t t_green; /* green exposure time */
uint16_t t_blue; /* blue exposure time */
unsigned char o_red; /* red offset */
unsigned char o_green; /* green offset */
unsigned char o_blue; /* blue offset */
unsigned char zero_2[3];
/* for a Reflecta ProScan 7200 in quality mode
the read gain values are usually one less than the written ones */
unsigned char g_red; /* red gain */
unsigned char g_green; /* green gain */
unsigned char g_blue; /* blue gain */
unsigned char t_some; /* time value, may correspond to
some_time[0] */
uint16_t t_min; /* minimal exposure time ??? */
unsigned char no_idea[20];
uint16_t t_ired; /* infrared exposure time */
unsigned char o_ired; /* infrared offset */
unsigned char zero_3;
unsigned char g_ired; /* infrared gain */
} __attribute__ ((__packed__)) PIE_USB_Calibration_Read;
I did some more scans without slide to describe the effect of different
gain settings. You find the data in
http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/status-180511/texp-1.ods
. There is an exponential relation between illumination (I) and gain
(g). For relatively low gain values (1f - 2b) I = aj * exp(c * g) * t is
sufficient to model the data in quality mode where ar, ag, ab and c were
least square fitted using the OpenOffice NLPsolver. At high gain
settings, however, the measured illumination would grow over
exponentially. So I finally settled with I = aj * exp(c * g^2) * t and
got a reasonable fit over the whole range of g.
I then made some scans in normal mode. More than 3/4 of them were
unusable. First of all they were extremely noisy with enormous
differences between min and max illumination values - my scanner uses
nearly maximal gain in normal mode. Then I constantly ran into zero
illumination when lowering gain or exposure. PIE must have applied a
weird offset to reach high illumination and short exposure. After a lot
of trying I came up with the following relation for normal mode I = n *
aj * exp(c * g^2) * t - (n - 1) * 65536 . For ar, ag, ab and c the same
values can be used as for quality mode. n is appr. 2 for my scanner, not
yours, it describes the difference between normal and quality mode.
My plans are to write some calibration routine - for quality mode first
- in which I derive the ar, ag, ab values from the read calibration
lines. Assuming that the d7-read tells me at which calibration the lines
were taken I can then calculate time and gain for the illumination I
wish to reach. c is the only value which I have to provide, sort of a
given gain constant.
I also used above assumptions with some values of snooped dc-write
values and come into the expected range for my scanner though green was
a bit weak. For your scanner I calculate less than half illumination but
very homogeneous RGB values. You must have a brighter lamp or get darker
images. With normal mode I am not sure yet. I think I leave it out at
the moment. For my scanner it seems more like crap mode - Silverfast
does not use it at all.
More to think about.
Regards
Michael
More information about the sane-devel
mailing list