[sane-devel] Canon LiDE 90

Sun Apr 6 17:06:04 UTC 2008

Hi Guillaume,

Sorry for not answering sooner.

Guillaume Gastebois schrieb:
> Hello,
> 
> Selon Pierre Willenbrock :
>> Guillaume Gastebois schrieb:
>>> > Hello,
>>> > > Yesterday I added CCD_CANONLIDE90 in genesys.c. I did two 
>>> successive scans
>>> > (result on http://ggastebois.free.fr/lide90_snoop/25_test1.zip).
>>> > The first one gives a bright image (1_test1.txt), the second a dark 
>>> image
>>> > (3_test1.txt). Which log seeems to be the best for calibration ? (in
>>> > 3_test1.txt, I see device I/O errors !!!)
>>> > What are good values for offset_calibration: black/white pixels ?
>>> > > Another thing : Pierre, you send me few weeks ago a code named 
>>> entropy2D.c. I
>>> > compile it with : gcc -c entropy2D.c, gcc -lm -o entropy2D 
>>> entropy2D.o. No
>>> > errors. I call it with entropy2D ./offset1_1.pnm and it makes 
>>> nothing and newer
>>> > gives hand back !!! What did I wrong ??? (I want to test common 
>>> nibbles).
>>
>> it accepts data on stdin, and outputs a pgm on stdout:
>> ./entropy2D < ./offset1_1.pnm > histogram.pgm
> 
> OK, works. Can you tell me what you think about attached image 
> (entropy2D of offset1_1.pnm) ?

The stairs at the top show that for two adjacent bytes, if the first 
byte is 0x00, the probability is high for the next byte to be in the 
range of 0x00 to 0x1f or 0x80 to 0x7f, for 0x02 the same with 0x20 to 
0x3f and 0xa0 to 0xbf:
0x00: 0x00..0x1f, 0x80..0x9f
0x02: 0x20..0x3f, 0xa0..0xbf
0x04: 0x40..0x5f, 0xc0..0xdf
0x06: 0x60..0x7f, 0xe0..0xff
Interestingly, the least significant bit of the first byte is nearly 
always 0. If it is not, it seems the second byte is then
0x01: 0x10..0x1f, 0x90..0x9f
0x03: 0x30..0x3f, 0xb0..0xbf
0x05: 0x50..0x5f, 0xd0..0xdf
At the left there are uncorrelated adjacent bytes(probably the second 
byte of one sample and the first byte of the next). Here, the lsb of the 
(now) second byte is nearly always 0, supporting the theory above.

This leads to my theory, that the higher nibble of second byte 
duplicates the lower nibble of the first byte, except for bit7, which 
seems uncorrelated.

Ideally, the first and second byte of a data sample are uncorrelated, 
leading to a uniform strip at the top and the left(very much like there 
is already on the left, but without the vertical bars).

>>
>>> > For scanner locks up writing 0x41=0xf4, It signify that scanner 
>>> things he's not
>>> > hat home position. (home position : 0x41=0xfc). I thing it will be 
>>> interessting
>>> > to move a little bit head. How to do that ? My explanation is that 
>>> on previous
>>> > scan, the head has pressed home switch, but if head after that 
>>> moves (less than
>>> > a millimeter is enought) switch can no more be pressed. So moving 
>>> back head may
>>> > be usefull (but Isn't still made ?)
>>
>> To my knowledge, if the backend tests register 0x41, it thinks the 
>> scanning head should be moving, but it apparently is not.
>>
> 
> I didn't see something important : it only apears on scanner powerup. 
> Locks up is away after pressing button 3 or 4 (not 1 ou 2 !). It's a 
> power up issue.

I can imagine that an incorrect setup of gpios leads to this.

>>> > > I did another ant work : comparing all regs from windows snoop to 
>>> sane and I
>>> > find these differences :
>>> > > addr |sane   |windows|comments
>>> > 
>>> _____|_______|_______|______________________________________________________ 
>>>
>>> > 09   |10     |21     |MCNTSET[1:0] CLKSET[1:0] BACKSCAN ENHANCE 
>>> SHORTTG NWAIT
>>> > 16   |20     |02     |CTRLHI TOSHIBA TGINV CK1INV CK2INV CTRLINV 
>>> CKDIS CTRLDIS
>>> > 19   |50     |ff     |EXPDMY[7:0]
>>> > 1a   |00     |24     |X X MANUAL3 MANUAL1 CK4INV CK3INV LINECLP X
>>> > 1d   |02     |04     |CK4LOW CK3LOW CK1LOW TGSHLD[4:0]
>>> > 52   |02     |02     |RHI[4:0]
>>> > 53   |07     |04     |RLOW[4:0]
>>> > 54   |00     |02     |GHI[4:0]
>>> > 55   |00     |04     |GLOW[4:0]
>>> > 56   |00     |02     |BHI[4:0]
>>> > 57   |00     |04     |BLOW[4:0]
>>> > 5d   |00     |20     |HISPD[7:0]
>>> > 5e   |02     |41     |DECSEL[2:0] STOPTIM[4:0]
>>> > 5f   |00     |40     |FMOVDEC[7:0]
>>> > 67   |00     |40     |STEPSEL[1:0] MTRPWM[5:0]
>>> > 68   |00     |40     |FSTPSEL[1:0] FASTPWM[5:0]
>>> > 69   |00     |08     |FSHDEC[7:0]
>>> > 6a   |00     |04     |FMOVNO[7:0]
>>> > 70   |21     |05     |X X X RSH[4:0]
>>> > 72   |00     |07     |X X X CPH[4:0]
>>> > 73   |00     |09     |X X X CPL[4:0]
>>> > 75   |00     |01     |CK1MAP[15:8]
>>> > 76   |00     |ff     |CK1MAP[7:0]
>>> > 79   |00     |3f     |CK3MAP[7:0]
>>> > 7c   |00     |1e     |CK4MAP[7:0]
>>> > 7d   |00     |11     |CK1NEG CK3NEG CK4NEG RSNEG CPNEG BSMPNEG 
>>> VSMPNEG DLYSET
>>> > 7f   |00     |50     |BSMPDLY[1:0] VSMPDLY[1:0] LEDCNT[3:0]
>>> > 82   |00     |0f     |ROFFSET[7:0]
>>> > 84   |00     |0e     |GOFFSET[7:0]
>>> > 86   |00     |0d     |BOFFSET[7:0]
>>> > > I think regs 09, 16, 19, 1a, 1d, 52, 53, 54, 55, 56, 57, 70, 72, 
>>> 73, 75, 76, 79,
>>> > 7c, 7d, 7f may be interessting, but I'll try to modify all.
> 
> If i write 0x16=02, 0x1a=24 and 0x1d=04 : I get some bad image (gray 
> with horizontal black lines).
> 
> With others regs, no change.

It could be interesting to play around with the other registers, when 
0x16/0x1a/0x1d are set.

>>> > > My next work will be analysing windows snoop for gpio transaction.
> 
> gpio18 and gpio17 are always 1. 0x6d 0x6e and 0x6f have alwase same 
> values (80 7f e0). Only 0x6c moves but I don't now how to know in 
> windows snoop when (before/after calibration/scanning...)

Then, doing the LiDE 35 gpio startup sequence seems to be unnecessary.

> Regards
> Guillaume

Now for the real reason i am answering: I did play around with my 
scanner, trying to get the shading calibration to work only on the white 
strip. The trick was to do a real scan over the white strip, not just 
sampling a single line over and over again. This is how it is done for 
the gl646 side, but i did disable that in my test-version because it led 
to fewer changes. For the LiDE 35, normally this is done, too, but over 
the full calibration area, which contains a white and a black strip. 
(That way, i get the white and black shading data in one scan. 
Obviously, this is only possible when there _is_ a black strip.)

This seems to indicate, that your problems with shading calibration are 
entirely based on the bad calibration of gain, offset or led exposure. 
The nibble-problem does not help, either.

Regards,
   Pierre