[sane-devel] Progress report on CanoScan 3200F: Now about shading

Lauri Pirttiaho lauri.pirttiaho at luukku.com
Wed Dec 14 21:05:04 UTC 2005


Progress report on CanoScan 3200F
---------------------------------

I have now been working on color scanning involving the internal
black/white shading compensation system. First, it was somewhat
difficult to figure out some problems in the scan head sticking
at the beginning. This led to two findings.

First was that the byte 26 of command vl=0030 has something to
do with the maximum stepper motor current -- maybe a current
limiter value or a voltage. Anyway, the procedure for this
apparently motor affecting value is as follows:
Before scan (or any motor movement) bits 5-4 of FFB0 are set
(i.e. @FFB0 |= 0x30). That register appears to be direction
register of general purpose IO. The corresponding data register
is FFB1 so the new motor control value is programmed as
@FFB1 = @FFB1 & 0xCF | 0xn0, where n is the wanted value 0, 1,
2, or 3. Typically 3 is used for movement (like head home)
and before scan. 3 is also used for 75 dpi scan. 1 is used
for 1200 dpi scan and 2 for all others. So the byte 26 of vl=0030
command is 0x10 for 1200 dpi, 0x20 for 150/300/600 dpi, and
0x30 for 75 dpi.

Also the main lamp and TA lamp are controlled though that same
GPIO. Main lamp is connected to bits 3-2 and TA lamp to bit 7.
Besides those register FFBF seems to be also somehow connected
with the main lamp. Since the light output seems to be lower
when the lamp is lit from there and not from FFB1, it may be
that FFBF is somehow related to the PWM control of the lamp
mentioned in the M5623 product brief.

The second finding was that the speed curves I mentioned in
my previous posting have to be more carefully designed.
I.e. too quick changes in acceleration and speed may drop
the motor out of phase and the head will stall.

Then about the more important finding, the shading control.
First, however, details of the byte 4 of vl=0030. That is
color mode selection. Values 0-2 are gray scale scans using
the reg/green/blue lines, respectively. Value 3 indicates
RGB color scan. Byte 6, low 4 bits of which go to register
FFE1, seems to control the shading/gamma processor. These
are presently unconfirmed but it seems that bit 0 is used
to switch on gamma processing and bits 1 and 2 seem to turn
on the shading processing, maybe offset on and gain on bits.
With bit 3 I have not yet gotten any effect.

Now, to the shading processor. It operates so that for each
color, the gain and offset values are programmed to 12
registers as 16-bit values. The registers are FF40-FF45 for
the gain (R,G,B 2 bytes each LSB first) and FF46-ff4B for
the offset. This value is used for the first pixel on each line
and the algorithm is the traditional one where from the data
coming from AFE the offset is first subtracted and then the
result is multiplied by 65536 and divided by the programmed
gain (i.e. inverse gain) value. For each subsequent pixel
a 16 bit offset value is taken from the data written to
memory at address 0x080000. Lowest 12 bits of that value
are a 2's complement value added to the gain and highest
4 bits are a 2's complement value added to the offset.

The procedure the driver seems to use to determine the
offsets and gains is, that it scans several lines first
with lamp off and then with lamp on. From the lamp-off
values the dark offset is calculated by averaging the lines
and then smoothing the curve along the CCD line (pixel
to pixel) using some kind of possibly polynomial fit.
The gain values are then adjusted so that the average
lamp-on values would scale to about 90% of maximum.
This is not the exact procedure the driver uses but
sufficiently close to the right one so that the image
quality is OK.

Having figured out that, I will now go back and try to put
all together. I have still problems with motor parameters
since the interrupt interval seems to affect the exposure
time also, and I have not yet figured out how the control
vectors at FA00 and FA80 are used to control the scanning.
Therefore, the playback of those vectors I get from my
XP machine (it has USB 2.0) seems to run the scanner too
fast for my Linux box (only USB 1.1 interfaces), and I
get a lot of back-tracking. I have not yet tried with my
newer Linuxes which have USB 2.0... I think I will try
to figure that out, too, before making a stand-alone
proof-of-concept trial program.

So, still a lot to do.

With best regards,

Lauri Pirttiaho
Oulu
Finland

...................................................................
Luukku Plus paketilla pääset eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku




More information about the sane-devel mailing list