[sane-devel] Reflecta ProScan 7200

Wed May 18 16:21:54 UTC 2011

Hi Jan,

Am 02.05.2011 22:46, schrieb Vleeshouwers, J.M.:
> Hi Michael,
>
> Enough stuff to think about. Some reactions and a couple of new topics
> as well.
>
>>> So, I guess under Windows shading correction is done in software
>>> as we assume already for gamma.
> I think so too. The scanner appears to be of a very basic type.
> Might be one of the reasons why PIE keep the software sources to
> themselves: the software is where the actual work is done. It also
> leaves us with very few parameters to explore, which might not be
> bad after all. If the basic functions needs software implementation, it
> may be slow but also versatile.
>
>>> In principle the 13 lines read for calibration are white but they
>>> also have vertical greyish bands. In the calibration lines the mean R, G
>>> or B value is about 55000 with roughly 2% standard deviation.
>>> Then I started changing the texp and gain values. The mean color values
>>> of the calibration lines was independent from that also when reading a
>>> second time after having changed texp or gain. The mean values varied a
>>> bit but perfectly stayed in the range of their standard deviations.
> That makes sense, doesn't it? You'd want to get calibration data in
> a standard way.
>
I know it differently from the genesys backend, and also the calibration 
procedure in the data sheet below would require some trial and error 
read and write.
>>> I think that we have to know exactly how to calibrate as we can not see
>>> the effect before scanning the image. For shading this must be something
>>> like a simple * TARGET / SHADE_VALUE operation as we only get one value
>>> per ccd pixel.
> I agree that a calibration procedure will have to decide upon appropriate
> values for exposure time, gain and offset (for each color separately).
> We don't know yet how, but there are defaults, see the values SCSI-DC outputs
> the very first time after switch-on. These values are always the same.
> After this initial SCSI-DC, the settings have to be based on the calibration
> data. I ran the scanner in Cyberview without a preview, and the SCSI-DC
> sends regular values to the scanner, without peeking at the slide.
> I found a couple of references to calibration and shading methods which
> are probably similar to the one we need and you describe, for example in
> http://www.national.com/ds/LM/LM9811.pdf, section 5 (somewhere at the end).
>
Yes, those are the basic steps. But I think that our scanners have done 
part of it already internally without producing USB traffic. We only get 
a few test lines without being able to change them. When I switch on my 
scanner it scans a few lines before it is ready. That must be sort of an 
internal calibration. We may succeed by only adjusting exposure time, 
gain and shading. The presumed offsets seem to be always copied from the 
preceding d7-calibration read.
>>> Next, I tried to find a relation between the texp values and the color
>>> values of the scanned image (300dpi, 16 bit, quality mode) still using
>>> the empty slide. My conclusions:
>>> 1) The three colors have to be treated separately.
>>> 2) The relation between texp setting and detected illumination can be
>>> described with a linear equation.
>>> 3) There is a minimal exposure time. With texp values below 0x0c00 you
>>> easily run into an undersaturation, especially in the blue channel.
> Conclusion 1 sounds right, probably valid for the infrared channel as well.
> The CCD has different filters for R, G, B and I, so there will be
> different optimal values for exposure, gain and offset.
> I would expect a linear relationship between exposure time and illumination
> since the number of incoming photons is linear with time. If it is linear
> with the texp values, then this value is just a straight integer (and not
> something fancy as a half precision real). That is good to know.
> I don't follow your conclusion on the minimal exposure time, maybe
> because I don't know what "undersaturated" means. If I interpret your
> measurements, I see that at a given texp, the blue response is larger than
> the green, which in turn is larger than the red response. That
> would correlate with the fact that in the snoops red_texp is usually bigger
> than the other two. If there is any channel at risk of being undersaturated,
> it would be the red channel.
>
What I meant is "time too short". It was especially apparent with the 
blue channel with lowering texps below 0c00 that illumination would not 
decrease any more or even increase again. With 0xc00 the scan head is 
really fast, judging from sound even faster than positioning speed. I 
guess that we will not need use that low exposure.

>>> I do not know what this leads to. A few thoughts: From a theoretical
>>> point of view in the equation "intensity_value = a * _texp + b" both a
>>> and b should change with the extinction of an pixel. A purely white
>>> image should give us the values which we need in our calibration
>>> function. Scanning an image twice with different texp should allow for
>>> calculation of the extinction of its pixel representation. How do
>>> different resolution settings affect the coefficents when ccd pixels are
>>> binned (or not)?
> I don't follow. What do you mean by "extinction" and "binned"?
>
What I meant with extinction (absorption, attenuation), is I = I0 * 
exp(coefficient * length). What I have measured is "I", the light having 
passed my empty slide. I have switched now to test runs without any 
slide as an approximation for I0. It often results in overexposed images 
which I have to discard, but for calculating it seems more honest.
I thought that when one has more ccd elements than output pixels one 
could accumulate some of the ccds (binned), one could average some, or 
leave some out. Detected illumination would change in the first case.

> I'm not completely sure, but could we assume we have these parameters at
> our disposal in SCSI-DC, extending PIE_USB_Calibration_Send a bit:
> The exposure time,  gain and offset settings for the four colors:
>    for RED:   texp = byte 0&  1, offset = byte 6, gain = byte 12
>    for GREEN: texp = byte 2&  3, offset = byte 7, gain = byte 13
>    for BLUE:  texp = byte 4&  5, offset = byte 8, gain = byte 14
>    for IR:    texp = byte 18&  19, offset = byte 20, gain = byte 22
> The remaining DC-bytes are byte 15 which is always 0x04 except at startup,
> byte 21 which is 0x68 at startup and then 0, and 9-11 which are always 0.
>
What I meant with extinction (absorption, attenuation), is I = I0 * 
exp(coefficient * length). What I have measured is "I", the light having 
passed my empty slide. I have switched now to test runs without any 
slide as an approximation for I0. It often results in overexposed images 
which I have to discard, but for calculating it seems more honest.
I thought that when one has more ccd elements than output pixels one 
could accumulate some of the ccds (binned), one could average some, or 
leave some out. Detected illumination would change in the first case.

> I have been wondering where the SCSI-18 (COPY) data fits in. If I
> compare the snoops, it seems more likely that has got
> to do with reading the scanned data. All scans with a given resolution
> have the same pattern of bytes. The number of bits set is related to the
> resolution, but inversely: the lower the resolution, the more bits set.
> Might it specify which CCD pixels have been used for the scan? If
> so, why would you want to know?
What I can think of at the moment is shading correction in software. To 
do that I will have to find the right offset and length in the read 
calibration lines for the scanned frame and then scale down the vector 
to the resolution used.

> You checked the ICs within the scanner, but you didn't by chance also
> identify the CCD? It might be helpful to know the type, e.g.
> if it is really a 5340-pixel type (such as Toshiba TCD2561,
> see http://www.digchip.com/data/487/487-12239-0-TCD2561D.pdf).
>
No, the CCD seems to be faced down covered by the scan head and I did 
not dare to do any mechanical manipulations except of powering off the 
scanner at positions of the scan head adequate for taking photos. Since 
there is this huge custom chip and PIE does not provide data it will be 
very difficult to go down to the basics. I think, that we will have to 
find a way to describe the scanners without explaining too much detail.

> Yours,
>
> Jan
I think this post becomes to long. So I will post separately with what I 
have found out in the meantime.
Regards
Michael