[sane-devel] Canon LiDE 90

Fri Feb 22 14:32:20 UTC 2008

Hi,

Guillaume Gastebois schrieb:
> Hello,
> 
> I updated from CVS and modified flag GENESYS_FLAG_DARK_WHITE_CALIBRATION
> in GENESYS_FLAG_DARK_CALIBRATION.
> 
> Summary of current modifications :
>     genesys_devices.c : see attachment
>     genesys_gl841.c : added SCAN_FLAG_DISABLE_LAMP (line 4461),
> commented "status = gl841_feed(dev, 280)" (line 4241 and 4843), modified
> 0 to 150 in "for (i = 150; i < num_pixels; i++)" (line 4617 and 4733).
       ^^^ 450 is probably still better.
> 
> Tonight I play with 52-57 regs.
> 
> I test 01/03/00/00/00/00, 01/04/00/00/00/00, 01/05/00/00/00/00,
> 02/03/00/00/00/00, 02/04/00/00/00/00, 02/05/00/00/00/00.

None of these are perfect, the best seems to be 2/4.

I thought a bit about these results, and conclude that this scanner does
not use a WM819x, which can output 2*8 bits, but instead uses one which
only does 4*4bits. This also matches that the chip did not react when
changing the data output mode.

As the GL842 cannot handle that format, another chip is put in between,
converting the 4*4 to 2*8bits. This way, when the analog frontend is
located in the scanning head, it is only needed to wire 4 data pins
instead of 8.

For correct timing, this seems to need additional clocks. We seem to be
always sampling on the signal edge, which leads to the glitches in the data.

(The chip in between is very probably the VHC175, latching its inputs on
the higher 4 bits from the AFE. Then, when the lower 4 bits are
available, the GL842 reads them directly from the AFE, together with the
high bits from the VHC175. Just the clock used by the VHC175 is not known.)

So, we need to check what parts of the clocking we need to setup
differently.

Candidates:

reg   sane  windows
0x1a  0x00  0x24     enable clock 3,4 manual output, invert clock 4
0x1d  0x04  0x02     just a smaller toggle "shoulder".
0x71  0x00  0x05     RS signal seems to be not used.
0x72  0x00  0x07     CP signal seems to be not used.
0x73  0x00  0x09     CP signal seems to be not used.
0x75  0x00  0x01     clock 1 bitmap
0x76  0x00  0xff     clock 1 bitmap
0x79  0x00  0x3f     clock 3 bitmap
0x7c  0x00  0x1e     clock 4 bitmap
0x7d  0x00  0x11     change RS on falling edge of system clock, use DLY
0x7f  0x00  0x50     delay each of BSMP and VSMP by 8.33ns (DLY)

The clock 1 stuff seems to be not needed, as it is in automatic mode.
But clock 3/4 look interesting. The delay of BSMP/VSMP may be useful, too.

> Result of experiment can be found on :
> http://ggastebois.free.fr/lide90_snoop/21_tests.tar
> 
> Is that true that as written in genesys_devices.c : "/*[GB](HI|LOW) not
> needed for cis */" because bests results are found with regs 52-57 with
> 01/03/05/07/09/11 !! Results of this test on :
> http://ggastebois.free.fr/lide90_snoop/21_test2.tar

Sorry, that one does look no better than the 01/03/00/00/00/00 variant.
Anyway, color scans would be missing colors if [GB](HI|LOW) were used.

> Another thing : I always have a brither vertical line where there is a
> small black rectangle in the calibration area.

The small black rectangle is included when acquiring the white level.
Reduce shading_lines(second to last entry) in Genesys_Model to 250, that
way it is not seen anymore.

> To finish, I find that images seems to be more in relief as reality. Do
> you understand what I say ? To speak clearly, when there is 0.1mm real
> relief between paper and glass, on the image we have an impression of
> 1mm relief ! Why ????

I don't know if you think of the same thing as i do, but the light and
optics are probably looking at the original at an angle, thus increasing
the size of shadows and other structures.

> Regards
> Guillaume

> P.S. : Where is located this new code for GENESYS_FLAG_DARK_CALIBRATION
> ? I used meld to see differences between my genesys_gl841.c file and
> this from CVS and only see my modifications !!!

The only thing that was missing was disabling the lamp when the
genesys_dark_shading_calibration requests that. That change is just the
small bit in genesys_gl841.c, gl841_set_lamp_power.

Oh, and please update from cvs again. A small mistake in
gl841_bulk_write_registers made the debug register dumps useless.

Regards,
  Pierre

> Pierre Willenbrock a écrit :
>> Pierre Willenbrock schrieb:
>>> Hi,
>>>
>>> Guillaume Gastebois schrieb:
>>>> Hello,
>>>>
>>>> So, what's the next step ? Re-enabling shading ?
>>> Yes, but only after the shading-calibration is able to get black level
>>> information.(This really needs a better api..)
>>
>> I commited a prerequisite for shading calibration to work for your
>> scanner. When enabling shading, update from cvs and then use
>> GENESYS_FLAG_DARK_CALIBRATION instead of
>> GENESYS_FLAG_DARK_WHITE_CALIBRATION.
>>
>> Regards,
>>   Pierre
>>
>>>> Do you think that last modification "for (i = 150; i..." is necessary ?
>>> Yes. Some time back, that part of the code just used the middle half of
>>> the scan, exactly to drop the dummy black pixels at the begin. That
>>> didn't work too well, missing some low black levels.
>>>
>>>> Is it time to fine tune registers 52... ?
>>> Try increasing register 53, 55, 57 by one. Attached is a small program,
>>> that shows the probability of any two-byte pair appearing in a file. It
>>> takes the file as input and dumps an portable anymap(pnm) as output.
>>> I created that program for something completely unrelated, but it proved
>>> useful.
>>>
>>> I used it on offset1_1.pnm(as offset1_0.pnm is only black).
>>> The image should show a fuzzy vertical and horizontal bar, near
>>> top/left. Currently, the horizontal bar is more a line, the vertical bar
>>> is correct(it shows the relationship between the low byte of one pixel
>>> and the high byte of the _next_ pixel).
>>>
>>>> Regards
>>>> Guillaume
>>> Regards,
>>>   Pierre
> 