Re: [sane-devel] Canon Lide 90 support

[Andre Wagner]

On Tue, Apr 3, 2018 at 10:24 PM,   wrote:






Hi,






I' m just switch a PC system from Windows to Linux including an old Canon Lide 
90 Scanner. I saw in Tour mailing list an old thread from 2008. Guillaume 
Gastebois and Pierre Willenbrock started at this time the development but did 
not finished it. I want to start a new attempt but all external links are in 
meanwhile invalid, so i got no base to start. Can somebody provide my the code 
written so far?






Thank you in advance














I actually also have a LiDE 90 I bought cheaply just to help development 
several years ago, but the hurdle was too much for me back then.






It would be nice to have another try though, so I will see if I can check out 
the git code and have a look to see the current status of the genesys backend.






Best regards,






Gernot Hassenpflug









Hi Gernot,
I also did so research on latest git version of sane backends. It seems that 
their code wasn't merged at all. Only a few snippets for an old thread 
(http://sane.10972.n7.nabble.com/Canon-LiDE-90-td11628.html) are available. 
They wrote that the GL842 chip used in the Canon Lide 90 is almost the same 
like then GL841 chip used in Canon Lide 35 and other older Canon Lide Models. 
As motor they assume it is the same like the motor in Canon LIDE 35, the analog 
frontend seams to be a Wolfson WM8192 (extracted from GL842 datasheet) or 
compatible. They assumed  CIS sensor used seams to be a compatible to the one 
used used in Canon Lide 35, but this model got only half of the resolution, so 
I think this assumption is perhaps not correct. I think Guillaume and Pierre 
developed an almost working code, but they have to give up on parametrisation 
of the AFE and black/white threshold, gamma correction, denoising etc. Since 
I'm working for an company which manufactures optical components I can use some 
test patterns for calibrating and can get perhaps some help of experts in 
optics.


Greetings,
André 


P.S.: I will do some USB traces with wireshark2 tomorrow, for figuring out the 
differences compared to the gl841 chip.



-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] Canon Lide 90 support

[Gernot Hassenpflug]

On Tue, Apr 3, 2018 at 10:24 PM,  wrote:

> Hi,
> I' m just switch a PC system from Windows to Linux including an old Canon
> Lide 90 Scanner. I saw in Tour mailing list an old thread from 2008.
> Guillaume Gastebois and Pierre Willenbrock started at this time the
> development but did not finished it. I want to start a new attempt but all
> external links are in meanwhile invalid, so i got no base to start. Can
> somebody provide my the code written so far?
> Thank you in advance
>

I actually also have a LiDE 90 I bought cheaply just to help development
several years ago, but the hurdle was too much for me back then.
It would be nice to have another try though, so I will see if I can check
out the git code and have a look to see the current status of the genesys
backend.
Best regards,
Gernot Hassenpflug
-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

[sane-devel] Canon Lide 90 support

[wagnerandre85]

Hi,
I' m just switch a PC system from Windows to Linux including an old Canon Lide 
90 Scanner. I saw in Tour mailing list an old thread from 2008. Guillaume 
Gastebois and Pierre Willenbrock started at this time the development but did 
not finished it. I want to start a new attempt but all external links are in 
meanwhile invalid, so i got no base to start. Can somebody provide my the code 
written so far?
Thank you in advance
-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

[sane-devel] Canon LiDE 90 or replacement cheap scanner

[Gernot Hassenpflug]

On Fri, Mar 12, 2010 at 11:03 PM, Mark J. Small msmall at eastlink.ca wrote:
 Hi everybody,

 I've looked through the lists for info about sane with a Canon LiDE 90. ?It
 looks like Guillaume Gastebois was working hard on it in 2008, but got bogged
 down in undocumented details.

 Is there any hope that this will ever work? ?I don't have the coding skills to
 help.

 Alternately, is there any currently available low cost scanner that has good
 sane support.

I don't know what low cost means in your area, nor whether these
models are available, but virtually all the Canon MP series up to the
700 series at least are supported (I have an MP710, the MP610 is
famous for Nicolas's work), including ADF on machines that have such a
feature, don't know about the latest on the 900 series.

Also, there are a couple of nice single-cable Canon USB scanners that
are perfect under linux: I have the N1240U, I think the N656U is also
supported. These are older now, maybe 4-5 years old but might be
available 2nd hand.

Regards,
  Gernot Hassenpflug

[sane-devel] Canon LiDE 90 or replacement cheap scanner

[Mark J. Small]

Hi everybody,

I've looked through the lists for info about sane with a Canon LiDE 90.  It 
looks like Guillaume Gastebois was working hard on it in 2008, but got bogged 
down in undocumented details.  

Is there any hope that this will ever work?  I don't have the coding skills to 
help.  

Alternately, is there any currently available low cost scanner that has good 
sane support.  

The Epson V300 needs a special driver that probably won't work on the arm box 
(QNAP Ts219P NAS with Debian) that I plan on use for my scanner server.

The HP G3110 has basic support only.

The Canon LiDE 100 and 200 have no support, and probably no hope for support.

Mark

[sane-devel] Canon LiDE 90

[Mike Silva]

Just like me, after seacrching for a simple, fast, cheap and relaiable 
(LED's instead of normal fluorescent light) scaner for linux, and after 
seing a scaned dinonsour in this mailing list :) using the canon LiDE 
90, I decided to buy this model (a month ago), but since I don0t use 
windows for some years on my desktop, this scaner it's still virgin in 
the original box waiting for an easy to test (user side) sane driver :)

Keep up the good investigation (I wish I could help)...
I did contact canon about a linux driver for this scaner, but their 
support team (outsourced) just said what we all know: not suported ny 
linux :(
I think not even the canon made the low lever windows driver, but meybe 
some taiwan chip maker or so...

There should be an easy way to use windows twain driver under wine, or 
something like MacOsX driver emulation for every diferent scaner...
Unfortunately, I've came to conclusion that lots of hardware starts to 
be well supported in linux drivers when it is discontinued :(

[sane-devel] Canon LiDE 90

[Robertawnh5]

I did the same today and was hoping to get it running in Kubuntu.  Just
posting to let you smart guys know that some of us ordinary users are very
interested in what you are doing.  Keep up the good work and when you are
ready for more testers let us know.  Thanks for your hard work.


Marc Massart wrote:
 
 
 
 
 
 
 Hi all, 
 
 I've bought recently a Canon LiDE 90 that ran fine under windows. But
 as I got fed up with Windows, I recently installed Linux (Suse 10.3)
 and I'm quite pleased with it. The only thing that doesn't seem to
 function is that Scanner from Canon. No need to say that Canon is not
 very helpful in providing a solution. The merely sent you a mail with a
 few links that are of no good use. 
 
 Browsing the web took me to this site and I could help noticing that
 some people where busy developing a driver themselves. 
 
 In the event that such a driver is written and ready to test, I'm
 willing to give it a try, just to see if it also works on my machine. 
 
 By the way, I'm new to Linux, I have an IBM Mainframe background. 
 
 Thank you for your time. 
 -- 
 
 
 
 
 
 
 
 
 
 Vriendelijke groeten, Best regards, Meilleurs salutations, 
 
 Marc. 
 
 
 Marc Massart 
 Boomgaardweg 39A 
 B-1640 Sint-Genesius-Rode 
 
 
 
 
 
 
 -- 
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org
 

-- 
View this message in context: 
http://www.nabble.com/Canon-LiDE-90-tp14851446p17027911.html
Sent from the SANE - Dev mailing list archive at Nabble.com.

[sane-devel] Canon LiDE 90

[Marc Massart]

An HTML attachment was scrubbed...
URL: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080412/037335de/attachment.htm
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Today : regression 

I tryed to remove lide 35 gpio sequence and to write 0x6b=0x6b  0x03. 
The result was : the motor try to move the head to home (but head is 
still home position). When I press a button, the scanner make a scan and 
... don't stop at the end. I see that pressing a button makes that the 
head stops. I don't understand because in windows snoop only 
GPIO14,13,12 and 11 moves.

I tryed writing 0x16=02 and 0x1a=24 and I get an Extremely low 
Brightness detected (I must open the trap to avoid this and get 
some black image...)

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello again,

By writing 0x6c=0x12 I have no more power-up problem and pressing 
buttons have no more effect on stopping head. Oufff

I tryed with 0x1a=24 and 0x16=02 : black image.

Remaining problem : nibbles and calibration.

Regards.
Guillaume

Guillaume Gastebois a ?crit :
 Hello,
 
 Today : regression 
 
 I tryed to remove lide 35 gpio sequence and to write 0x6b=0x6b  0x03. 
 The result was : the motor try to move the head to home (but head is 
 still home position). When I press a button, the scanner make a scan and 
 ... don't stop at the end. I see that pressing a button makes that the 
 head stops. I don't understand because in windows snoop only 
 GPIO14,13,12 and 11 moves.
 
 I tryed writing 0x16=02 and 0x1a=24 and I get an Extremely low 
 Brightness detected (I must open the trap to avoid this and get 
 some black image...)
 
 Regards
 Guillaume
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

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 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Pierre Willenbrock schrieb:
 
 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.)

To clarify this, my patch (and probably your code base) does a scan over 
the strip, too.

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I write again about LiDE 90 because I had no answers since my last mail.

Does people who test my patch have results...

Please see my last mail. I did any progress since it.

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

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) ?
 
  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 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.

  
  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...)

  
  Regards
  Guillaume
  
 

Regards
Guillaume
-- next part --
A non-text attachment was scrubbed...
Name: test.pnm.tar.gz
Type: application/x-gzip
Size: 4650 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080327/55f581d1/attachment.bin
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

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).

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 ?)

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.

My next work will be analysing windows snoop for gpio transaction.

Regards
Guillaume

[sane-devel] Canon LiDE 90

[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

 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 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.
 
 My next work will be analysing windows snoop for gpio transaction.
 
 Regards
 Guillaume
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

You can find attached a patch which works like my original code (with 
different contrast and calibration between 2 scans...).

I removed controversed comments (sorry).

I see in some case that my scanner locks writing : [genesys] 
sanei_genesys_read_register (0x41, 0xf4) completed and to unlock I have 
to push one of the 4 buttons !! Idea about that ?

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Hi Guillaume,
 
 Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Pierre Willenbrock schrieb:
 But this seems to be basically working. Please send your changes 
 leading
 to a usable scan, so i can integrate them.
 For now, my code is ugly. I only modified lide60 to lide90. But you 
 can find genesys_gl841.c and genesys_devices.c in 
 http://ggastebois.free.fr/lide90_snoop/sources

 Will merge that.

 
 please check if the attached patch against current cvs gives basic 
 scanning ability with the Canon LiDE 90.
 
 Sorry for the delay.
 
 Regards,
   Pierre
 
-- next part --
A non-text attachment was scrubbed...
Name: canon-lide-90.diff
Type: text/x-patch
Size: 8854 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080319/09c9152f/attachment.bin
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 You can find attached a patch which works like my original code (with 
 different contrast and calibration between 2 scans...).
 
 I removed controversed comments (sorry).

Thanks for the patch. I see that you added DAC_CANONLIDE90 at one place. 
  This is probably needed at others places, too. (especially in 
genesys.c, iirc the way to encode the shading calibration data depends 
on one of the xx_type variables.)

Then i see the LiDE 35's GPIO initialization sequence is used. Are you 
willing to play around with the involved bits to find the state 
transitions that don't reset the scanner? This is not strictly 
necessary, as the sequence works. But there may be some subtleties 
hiding there. Try adding delays between the state transitions when 
testing that, fast switching through the sequence sometimes leads to 
inconsistent results. (By state i mean the state of the gpio pins 
configured as output.)

For the LiDE 35 i found at least these constraints(i had a small state 
table that showed the allowed transitions, but i can't find it now):
- GPO17 cannot be switched on when GPIO8 is off
- GPIO9 cannot be switched off when GPIO8 is off

 I see in some case that my scanner locks writing : [genesys] 
 sanei_genesys_read_register (0x41, 0xf4) completed and to unlock I have 
 to push one of the 4 buttons !! Idea about that ?

The scan is not starting for some reason. I don't know what causes that. 
May be a power issue, depending on correctly setting the gpios or sth 
like that.

 Regards
 Guillaume

Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Ralf Haueisen schrieb:
 I tried again, an now not even pressing a button help.
 What code do you need, and how can i get it?
 

Please try the patch from Guillaume Gastebois.

Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
   Hello,
  
   You can find attached a patch which works like my original code (with
   different contrast and calibration between 2 scans...).
  
   I removed controversed comments (sorry).
 
 Thanks for the patch. I see that you added DAC_CANONLIDE90 at one place.
   This is probably needed at others places, too. (especially in
 genesys.c, iirc the way to encode the shading calibration data depends
 on one of the xx_type variables.)
 
DAC_CANONLIDE90 appears only in genesys_devices.c and genesys_gl841.c.

 Then i see the LiDE 35's GPIO initialization sequence is used. Are you
 willing to play around with the involved bits to find the state
 transitions that don't reset the scanner? This is not strictly
 necessary, as the sequence works. But there may be some subtleties

If i dont add same constraint as lide 35 I get black image output.

 hiding there. Try adding delays between the state transitions when
 testing that, fast switching through the sequence sometimes leads to
 inconsistent results. (By state i mean the state of the gpio pins
 configured as output.)
 
How to do that 

 For the LiDE 35 i found at least these constraints(i had a small state
 table that showed the allowed transitions, but i can't find it now):
 - GPO17 cannot be switched on when GPIO8 is off
 - GPIO9 cannot be switched off when GPIO8 is off
 
   I see in some case that my scanner locks writing : [genesys]
   sanei_genesys_read_register (0x41, 0xf4) completed and to unlock I have
   to push one of the 4 buttons !! Idea about that ?
 
 The scan is not starting for some reason. I don't know what causes that.
 May be a power issue, depending on correctly setting the gpios or sth
 like that.

The windows snoop may say that but I remember fixing gpio regs with thos
snoop
Must be investigated but later.

 
   Regards
   Guillaume
 
 Regards,
Pierre

It remains the bigest problem : calibration. Because I get different
contrast and sometimes vertical contrasted lines (bad shading). To be
continued.


Regards
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
   Hello,
  
   You can find attached a patch which works like my original code (with
   different contrast and calibration between 2 scans...).
  
   I removed controversed comments (sorry).

 Thanks for the patch. I see that you added DAC_CANONLIDE90 at one place.
   This is probably needed at others places, too. (especially in
 genesys.c, iirc the way to encode the shading calibration data depends
 on one of the xx_type variables.)

 DAC_CANONLIDE90 appears only in genesys_devices.c and genesys_gl841.c.

(i think you meant DAC_CANONLIDE35.) That is correct, but there is also 
CCD_CANONLIDE35, which is used in genesys.c when setting up the shading 
calibration data.

 
 Then i see the LiDE 35's GPIO initialization sequence is used. Are you
 willing to play around with the involved bits to find the state
 transitions that don't reset the scanner? This is not strictly
 necessary, as the sequence works. But there may be some subtleties
 
 If i dont add same constraint as lide 35 I get black image output.

see? mine does simply powercycle when trying to use it without that 
(not so) magic sequence.

 hiding there. Try adding delays between the state transitions when
 testing that, fast switching through the sequence sometimes leads to
 inconsistent results. (By state i mean the state of the gpio pins
 configured as output.)

 How to do that 

I used my small test program[1], modified to exercise the transitions of 
interest. As i mentioned above, my scanner is pretty unforgiving to the 
wrong sequence, so the program failed early when something went wrong.

 For the LiDE 35 i found at least these constraints(i had a small state
 table that showed the allowed transitions, but i can't find it now):
 - GPO17 cannot be switched on when GPIO8 is off
 - GPIO9 cannot be switched off when GPIO8 is off

   I see in some case that my scanner locks writing : [genesys]
   sanei_genesys_read_register (0x41, 0xf4) completed and to unlock I have
   to push one of the 4 buttons !! Idea about that ?

replugging does help, too? (If not, this may be interesting)

 The scan is not starting for some reason. I don't know what causes that.
 May be a power issue, depending on correctly setting the gpios or sth
 like that.
 
 The windows snoop may say that but I remember fixing gpio regs with thos
 snoop
 Must be investigated but later.
 
   Regards
   Guillaume

 Regards,
Pierre
 
 It remains the bigest problem : calibration. Because I get different
 contrast and sometimes vertical contrasted lines (bad shading). To be
 continued.

Another problem is the duplicated nibble in the data from the afe.

At least now there is a patch enabling basic support for this scanner, 
which could be integrated into sane without causing the other scanners 
to stop working.

 Regards
 Guillaume

Regards,
   Pierre

[1] http://pirsoft-dsl-dropzone.de/canon-lide35.tbz2

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

 Guillaume Gastebois schrieb:
 Hello,
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
   Hello,
  
   You can find attached a patch which works like my original code (with
   different contrast and calibration between 2 scans...).
  
   I removed controversed comments (sorry).

 Thanks for the patch. I see that you added DAC_CANONLIDE90 at one place.
   This is probably needed at others places, too. (especially in
 genesys.c, iirc the way to encode the shading calibration data depends
 on one of the xx_type variables.)

 DAC_CANONLIDE90 appears only in genesys_devices.c and genesys_gl841.c.
 
 (i think you meant DAC_CANONLIDE35.) That is correct, but there is also 
 CCD_CANONLIDE35, which is used in genesys.c when setting up the shading 
 calibration data.
 
Yes Ithink DAC_CANONLIDE35. I added CCD_CANONLIDE90 in genesys.c too. 
You were true.

 
 Then i see the LiDE 35's GPIO initialization sequence is used. Are you
 willing to play around with the involved bits to find the state
 transitions that don't reset the scanner? This is not strictly
 necessary, as the sequence works. But there may be some subtleties
 
 If i dont add same constraint as lide 35 I get black image output.
 
 see? mine does simply powercycle when trying to use it without that 
 (not so) magic sequence.
 
 hiding there. Try adding delays between the state transitions when
 testing that, fast switching through the sequence sometimes leads to
 inconsistent results. (By state i mean the state of the gpio pins
 configured as output.)

 How to do that 
 
 I used my small test program[1], modified to exercise the transitions of 
 interest. As i mentioned above, my scanner is pretty unforgiving to the 
 wrong sequence, so the program failed early when something went wrong.
 
I'll try to adapt it. Thanks.

 For the LiDE 35 i found at least these constraints(i had a small state
 table that showed the allowed transitions, but i can't find it now):
 - GPO17 cannot be switched on when GPIO8 is off
 - GPIO9 cannot be switched off when GPIO8 is off

   I see in some case that my scanner locks writing : [genesys]
   sanei_genesys_read_register (0x41, 0xf4) completed and to unlock I have
   to push one of the 4 buttons !! Idea about that ?
 
 replugging does help, too? (If not, this may be interesting)
Replugging doesn't change this problem. In my first test I have to press 
  button 3 (lide 90 has 4) to unlock scanner  
 
 The scan is not starting for some reason. I don't know what causes that.
 May be a power issue, depending on correctly setting the gpios or sth
 like that.
 
 The windows snoop may say that but I remember fixing gpio regs with thos
 snoop
 Must be investigated but later.
 
   Regards
   Guillaume

 Regards,
Pierre
 
 It remains the bigest problem : calibration. Because I get different
 contrast and sometimes vertical contrasted lines (bad shading). To be
 continued.
 
 Another problem is the duplicated nibble in the data from the afe.
Yep I forget this big problem (My mind want to be closest to the end!!!)
 
 At least now there is a patch enabling basic support for this scanner, 
 which could be integrated into sane without causing the other scanners 
 to stop working.
 
 Regards
 Guillaume
 
 Regards,
Pierre
 
 [1] http://pirsoft-dsl-dropzone.de/canon-lide35.tbz2

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Hi Guillaume,

Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Pierre Willenbrock schrieb:
 But this seems to be basically working. Please send your changes leading
 to a usable scan, so i can integrate them.
 For now, my code is ugly. I only modified lide60 to lide90. But you can 
 find genesys_gl841.c and genesys_devices.c in 
 http://ggastebois.free.fr/lide90_snoop/sources
 
 Will merge that.
 

please check if the attached patch against current cvs gives basic 
scanning ability with the Canon LiDE 90.

Sorry for the delay.

Regards,
   Pierre
-- next part --
A non-text attachment was scrubbed...
Name: canon-lide-90.diff
Type: text/x-patch
Size: 7930 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080319/9f3fa7bd/attachment.bin
 

[sane-devel] Canon LiDE 90

[Volker Grabsch]

On Wed, Mar 19, 2008 at 03:24:45PM +0100, Pierre Willenbrock wrote:
 +  ,
 +  /* CANONLIDE90 */
 +  {
 +/*
 +00 :
 +02 : image ?? la con et inverse video
 +0a : image ?? la con et inverse video et moteur ne stoppe pas ?? la fin du 
 scan
 +0e : ne reconnait plus la position home
 +10 : mieux toujours une ligne verticale ?? gauche et en inverse video
 +12 : comme 10
 +18 : comme 10
 +1a : comme 10
 +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en largeur
 +3a : comme 38
 +3e : comme 0e
 +3c : le moteur essaye en vain de tourner
 +*/

Why are these comments written in french instead of english?


Greets,

Volker

-- 
Volker Grabsch
---(())---
Administrator
NotJustHosting GbR

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Volker Grabsch schrieb:
 On Wed, Mar 19, 2008 at 03:24:45PM +0100, Pierre Willenbrock wrote:
 +  ,
 +  /* CANONLIDE90 */
 +  {
 +/*
 +00 :
 +02 : image ?? la con et inverse video
 +0a : image ?? la con et inverse video et moteur ne stoppe pas ?? la fin du 
 scan
 +0e : ne reconnait plus la position home
 +10 : mieux toujours une ligne verticale ?? gauche et en inverse video
 +12 : comme 10
 +18 : comme 10
 +1a : comme 10
 +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en largeur
 +3a : comme 38
 +3e : comme 0e
 +3c : le moteur essaye en vain de tourner
 +*/
 
 Why are these comments written in french instead of english?
 

These are from his original sources. I couldn't match the other two to 
the right values. The translation for these is somewhere in the mail 
archive, but i was too lazy to dig them out. I don't speak french, so 
i'd be grateful if someone translates the other two instances. On the 
other hand, it is probably better to put this info into the page of this 
scanner:
http://www.sane-project.org/unsupported/canon-lide-90.html

 Greets,
 
 Volker

Regards,
   Pierre

[sane-devel] Canon LiDE 90

[s...@tsleg.com]

Hi,

It's just because they come from temporary code from a French person. As 
I'm french to, I'll translate for you ;)

(I'll not translate word by word, cause image ? la con means something 
like fucking picture)
 +02 : image ?? la con et inverse video
dirty inverted picture
 +0a : image ?? la con et inverse video et moteur ne stoppe pas ?? la fin du 
 scan
 
dirty inverted picture and engine doesn't stop at the end of the scan
 +0e : ne reconnait plus la position home
 
Can't go back home
 +10 : mieux toujours une ligne verticale ?? gauche et en inverse video
 
better with a vertical ligne at the left and inverted picture
 +12 : comme 10
 +18 : comme 10
 +1a : comme 10
 
like 10
 +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en largeur
 
great picture but 50% stretch
 +3a : comme 38
 +3e : comme 0e
 
like 38, 0e
 +3c : le moteur essaye en vain de tourner
 
Engine tries to run

 Why are these comments written in french instead of english?


 Greets,

 Volker

   

[sane-devel] Canon LiDE 90

[Ralf Haueisen]

Hi.

I just downloaded the current version from the CVS, an applied the patches. But 
sane does not find the scanner.
sane-find-scanner is ok, but scanimage not. in /etc/sane.d/genesys.conf I have 
added the ID of the scanner.
I tried everything as root, so acces-rights should not be the reason.

Ralf

 -Urspr?ngliche Nachricht-
 Von: Pierre Willenbrock pierre at pirsoft.dnsalias.org
 Gesendet: 19.03.08 16:54:14
 An: Volker Grabsch vog at notjusthosting.com
 CC: sane-devel at lists.alioth.debian.org
 Betreff: Re: [sane-devel] Canon LiDE 90


 
 Volker Grabsch schrieb:
  On Wed, Mar 19, 2008 at 03:24:45PM +0100, Pierre Willenbrock wrote:
  +  ,
  +  /* CANONLIDE90 */
  +  {
  +/*
  +00 :
  +02 : image ?? la con et inverse video
  +0a : image ?? la con et inverse video et moteur ne stoppe pas ?? la fin 
  du scan
  +0e : ne reconnait plus la position home
  +10 : mieux toujours une ligne verticale ?? gauche et en inverse video
  +12 : comme 10
  +18 : comme 10
  +1a : comme 10
  +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en largeur
  +3a : comme 38
  +3e : comme 0e
  +3c : le moteur essaye en vain de tourner
  +*/
  
  Why are these comments written in french instead of english?
  
 
 These are from his original sources. I couldn't match the other two to 
 the right values. The translation for these is somewhere in the mail 
 archive, but i was too lazy to dig them out. I don't speak french, so 
 i'd be grateful if someone translates the other two instances. On the 
 other hand, it is probably better to put this info into the page of this 
 scanner:
 http://www.sane-project.org/unsupported/canon-lide-90.html
 
  Greets,
  
  Volker
 
 Regards,
Pierre
 
 -- 
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org
 


_
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

[sane-devel] Canon LiDE 90

[Ralf Haueisen]

Pressing any button on the scanner helped

this is the output of scanimage:
[genesys_gl841] **
[genesys_gl841] **
[genesys_gl841]   
[genesys_gl841]   Extremely low Brightness detected.  
[genesys_gl841]   Check the scanning head is  
[genesys_gl841]   unlocked and moving.
[genesys_gl841]   
[genesys_gl841] **
[genesys_gl841] **
scanimage: sane_start: Document feeder jammed

Maybe this is a useful help for the test of the patches.

Ralf

 -Urspr?ngliche Nachricht-
 Von: Ralf Haueisen ralf.haueisen at web.de
 Gesendet: 19.03.08 17:21:02
 An: sane-devel at lists.alioth.debian.org
 Betreff: Re: [sane-devel] Canon LiDE 90


 
 Hi.
 
 I just downloaded the current version from the CVS, an applied the patches. 
 But sane does not find the scanner.
 sane-find-scanner is ok, but scanimage not. in /etc/sane.d/genesys.conf I 
 have added the ID of the scanner.
 I tried everything as root, so acces-rights should not be the reason.
 
 Ralf
 
  -Urspr?ngliche Nachricht-
  Von: Pierre Willenbrock pierre at pirsoft.dnsalias.org
  Gesendet: 19.03.08 16:54:14
  An: Volker Grabsch vog at notjusthosting.com
  CC: sane-devel at lists.alioth.debian.org
  Betreff: Re: [sane-devel] Canon LiDE 90
 
 
  
  Volker Grabsch schrieb:
   On Wed, Mar 19, 2008 at 03:24:45PM +0100, Pierre Willenbrock wrote:
   +  ,
   +  /* CANONLIDE90 */
   +  {
   +/*
   +00 :
   +02 : image ?? la con et inverse video
   +0a : image ?? la con et inverse video et moteur ne stoppe pas ?? la fin 
   du scan
   +0e : ne reconnait plus la position home
   +10 : mieux toujours une ligne verticale ?? gauche et en inverse video
   +12 : comme 10
   +18 : comme 10
   +1a : comme 10
   +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en largeur
   +3a : comme 38
   +3e : comme 0e
   +3c : le moteur essaye en vain de tourner
   +*/
   
   Why are these comments written in french instead of english?
   
  
  These are from his original sources. I couldn't match the other two to 
  the right values. The translation for these is somewhere in the mail 
  archive, but i was too lazy to dig them out. I don't speak french, so 
  i'd be grateful if someone translates the other two instances. On the 
  other hand, it is probably better to put this info into the page of this 
  scanner:
  http://www.sane-project.org/unsupported/canon-lide-90.html
  
   Greets,
   
   Volker
  
  Regards,
 Pierre
  
  -- 
  sane-devel mailing list: sane-devel at lists.alioth.debian.org
  http://lists.alioth.debian.org/mailman/listinfo/sane-devel
  Unsubscribe: Send mail with subject unsubscribe your_password
   to sane-devel-request at lists.alioth.debian.org
  
 
 
 _
 In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
 Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
 
 
 -- 
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org
 


__
Bis 50 MB Dateianh?nge? Kein Problem!
http://freemail.web.de/club/landingpage.htm/?mc=025556

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Ralf Haueisen schrieb:
 Hi.
 
 I just downloaded the current version from the CVS, an applied the patches. 
 But sane does not find the scanner.
 sane-find-scanner is ok, but scanimage not. in /etc/sane.d/genesys.conf I 
 have added the ID of the scanner.
 I tried everything as root, so acces-rights should not be the reason.
 
 Ralf
 

Does scanimage -L list the scanner? If not, i need to look deeper into 
the probing-code..

Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Ralf Haueisen]

I tried again, an now not even pressing a button help.
What code do you need, and how can i get it?

 -Urspr?ngliche Nachricht-
 Von: Pierre Willenbrock pierre at pirsoft.dnsalias.org
 Gesendet: 19.03.08 17:53:48
 An: sane-devel at lists.alioth.debian.org
 Betreff: Re: [sane-devel] Canon LiDE 90


 
 Ralf Haueisen schrieb:
  Hi.
  
  I just downloaded the current version from the CVS, an applied the patches. 
  But sane does not find the scanner.
  sane-find-scanner is ok, but scanimage not. in /etc/sane.d/genesys.conf I 
  have added the ID of the scanner.
  I tried everything as root, so acces-rights should not be the reason.
  
  Ralf
  
 
 Does scanimage -L list the scanner? If not, i need to look deeper into 
 the probing-code..
 
 Regards,
Pierre
 
 -- 
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org
 


___
Jetzt neu! Sch?tzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,


   Volker Grabsch schrieb:
 On Wed, Mar 19, 2008 at 03:24:45PM +0100, Pierre Willenbrock wrote:
 +  ,
 +  /* CANONLIDE90 */
 +  {
 +/*
 +00 :
 +02 : image ?? la con et inverse video
 +0a : image ?? la con et inverse video et moteur ne stoppe 
pas ?? la fin du scan
 +0e : ne reconnait plus la position home
 +10 : mieux toujours une ligne verticale ?? gauche et en 
inverse video
 +12 : comme 10
 +18 : comme 10
 +1a : comme 10
 +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en 
largeur
 +3a : comme 38
 +3e : comme 0e
 +3c : le moteur essaye en vain de tourner
 +*/

 Why are these comments written in french instead of english?

  

I'm the author of these unpolite comments. These were written for my 
personnal information and developpement. I forget to delete them. I 
think they must be deleted from patch.

Regards

Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 
Volker Grabsch schrieb:
  On Wed, Mar 19, 2008 at 03:24:45PM +0100, Pierre Willenbrock wrote:
  +  ,
  +  /* CANONLIDE90 */
  +  {
  +/*
  +00 :
  +02 : image ?? la con et inverse video
  +0a : image ?? la con et inverse video et moteur ne stoppe 
 pas ?? la fin du scan
  +0e : ne reconnait plus la position home
  +10 : mieux toujours une ligne verticale ?? gauche et en 
 inverse video
  +12 : comme 10
  +18 : comme 10
  +1a : comme 10
  +38 : image de tr??s bonne qualit?? mais ecras??e de 50% en 
 largeur
  +3a : comme 38
  +3e : comme 0e
  +3c : le moteur essaye en vain de tourner
  +*/
 
  Why are these comments written in french instead of english?
 
   
 
 I'm the author of these unpolite comments. These were written for my 
 personnal information and developpement. I forget to delete them. I 
 think they must be deleted from patch.
 
 Regards
 
 Guillaume

I won't argue with the author, so i will not commit these comments. I 
see that my proposed patch does not work for at least one Canon LiDE 90 
owner. Does it work for you?

Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I do the test again with :

0x71] = 0x05; /*RS signal seems to be not used.*/
0x72] = 0x07; /*CP signal seems to be not used.*/
0x73] = 0x09; /*CP signal seems to be not used.*/
0x75] = 0x01; /*clock 1 bitmap*/
0x76] = 0xff; /*clock 1 bitmap*/
0x79] = 0x3f; /*clock 3 bitmap*/
0x7c] = 0x1e; /*clock 4 bitmap*/
0x7d] = 0x11; /*change RS on falling edge of system clock, use DLY*/
0x7f] = 0x50; /*delay each of BSMP and VSMP by 8.33ns (DLY)*/

The result is on : http://ggastebois.free.fr/lide90_snoop/12_test1.tar
(and a second scan on : 
http://ggastebois.free.fr/lide90_snoop/12_test1b.tar)

Pierre Willenbrock a ?crit :
 Hi,
 
 Guillaume Gastebois schrieb:
 Hello,


 What about only setting register 0x7f? that one should do something
 without needing to setup reg 0x1a.
 Not better I think. Result : 
 http://ggastebois.free.fr/lide90_snoop/10_test0.tar
 
 I forgot that there is a switch-on-bit for that, too: bit0 of reg[0x7d].
 Please try with that one set.
 (And that tar seems to be truncated)
 
 I didn't expect reg[0x1a]=0x24 to work without setting the corresponding
 clock bit masks. What happens if you leave line 1159 commented and set
 regs 0x74-0x7d(my guess: works without changes in behaviour)? Does
 setting regs 0x71-0x73 change anything (line 1159 still commented)?

 Result of setting only 0x75 0x76 0x79 0x7c 0x7d (not 0x7f) : 
 http://ggastebois.free.fr/lide90_snoop/10_test1.tar

 Result of setting 0x71 0x72 0x73 0x75 0x76 0x79 0x7c 0x7d (not 0x7f) :
 http://ggastebois.free.fr/lide90_snoop/10_test2.tar
 
 The same as without setting them at all. So the bits in 0x1a are
 probably switching from some internal bit masks to those in 0x71 to
 0x7c. And changing the switching point of RS didn't change anything, either.
 
 (I have only little understanding of the actual relative timing and use
 of all clock signals going out to the ccd/afe, so i am guessing and
 doing experiments.)

 But this seems to be basically working. Please send your changes leading
 to a usable scan, so i can integrate them.
 For now, my code is ugly. I only modified lide60 to lide90. But you can 
 find genesys_gl841.c and genesys_devices.c in 
 http://ggastebois.free.fr/lide90_snoop/sources
 
 Will merge that.
 
 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???
 The calibration is probably giving widely differing results with
 different starting conditions. It swings between two states. But you
 shouldn't see this after the gl842 did its shading correction. Then, the
 problem is probably overexposure of the ccd cells. Try reducing the
 upper threshold in genesys_gl841.c:4383

   if (avge  2000) {
   expr = (expr * 2000) / avge;
   expg = (expg * 2000) / avge;
   expb = (expb * 2000) / avge;

 Reducing the lower threshold may be needed, too. The current values for
 your scanner are:
 expr: 1235
 expg: 1235
 expb: 675

 No guarantee that this helps at all.
 I tryed that (upper threshold to 1500 and lower to 250 and it doesn't 
 work. You can find the same test as test2 without the same result on : 
 http://ggastebois.free.fr/lide90_snoop/10_test2b.tar (I just make two 
 consecutive scanimage without recompiling sane).
 
 That is not unexpected.

Any other idea ?

 
 One other thing : we can see vertical lines with different contrast on 
 result images. What is it ?
 
 The shading correction not doing its work correctly. I see similar
 behavior when using the method of scanning a single line multiple times
 with/without lights for acquisition of dark/bright levels. I don't see
 this when using a scan over my black+white calibration area. Currently,
 i don't know what causes this difference.

But there is not black area on lide 90 (except the small rectangle in 
the middle (for glass fixing ?)). Shading must be possible with led off 
!!! (but I'm not a specialist!!!)
 
 Regards
 Guillaume
 
 Regards,
   Pierre
 
 

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Hi,

Guillaume Gastebois schrieb:
 Hello,
 
 
 What about only setting register 0x7f? that one should do something
 without needing to setup reg 0x1a.
 
 Not better I think. Result : 
 http://ggastebois.free.fr/lide90_snoop/10_test0.tar

I forgot that there is a switch-on-bit for that, too: bit0 of reg[0x7d].
Please try with that one set.
(And that tar seems to be truncated)

 I didn't expect reg[0x1a]=0x24 to work without setting the corresponding
 clock bit masks. What happens if you leave line 1159 commented and set
 regs 0x74-0x7d(my guess: works without changes in behaviour)? Does
 setting regs 0x71-0x73 change anything (line 1159 still commented)?

 Result of setting only 0x75 0x76 0x79 0x7c 0x7d (not 0x7f) : 
 http://ggastebois.free.fr/lide90_snoop/10_test1.tar
 
 Result of setting 0x71 0x72 0x73 0x75 0x76 0x79 0x7c 0x7d (not 0x7f) :
 http://ggastebois.free.fr/lide90_snoop/10_test2.tar

The same as without setting them at all. So the bits in 0x1a are
probably switching from some internal bit masks to those in 0x71 to
0x7c. And changing the switching point of RS didn't change anything, either.

 (I have only little understanding of the actual relative timing and use
 of all clock signals going out to the ccd/afe, so i am guessing and
 doing experiments.)

 But this seems to be basically working. Please send your changes leading
 to a usable scan, so i can integrate them.
 For now, my code is ugly. I only modified lide60 to lide90. But you can 
 find genesys_gl841.c and genesys_devices.c in 
 http://ggastebois.free.fr/lide90_snoop/sources

Will merge that.

 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???
 The calibration is probably giving widely differing results with
 different starting conditions. It swings between two states. But you
 shouldn't see this after the gl842 did its shading correction. Then, the
 problem is probably overexposure of the ccd cells. Try reducing the
 upper threshold in genesys_gl841.c:4383

if (avge  2000) {
expr = (expr * 2000) / avge;
expg = (expg * 2000) / avge;
expb = (expb * 2000) / avge;

 Reducing the lower threshold may be needed, too. The current values for
 your scanner are:
 expr: 1235
 expg: 1235
 expb: 675

 No guarantee that this helps at all.
 I tryed that (upper threshold to 1500 and lower to 250 and it doesn't 
 work. You can find the same test as test2 without the same result on : 
 http://ggastebois.free.fr/lide90_snoop/10_test2b.tar (I just make two 
 consecutive scanimage without recompiling sane).

That is not unexpected.

 One other thing : we can see vertical lines with different contrast on 
 result images. What is it ?

The shading correction not doing its work correctly. I see similar
behavior when using the method of scanning a single line multiple times
with/without lights for acquisition of dark/bright levels. I don't see
this when using a scan over my black+white calibration area. Currently,
i don't know what causes this difference.

 Regards
 Guillaume

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,


 What about only setting register 0x7f? that one should do something
 without needing to setup reg 0x1a.

Not better I think. Result : 
http://ggastebois.free.fr/lide90_snoop/10_test0.tar
 
 I didn't expect reg[0x1a]=0x24 to work without setting the corresponding
 clock bit masks. What happens if you leave line 1159 commented and set
 regs 0x74-0x7d(my guess: works without changes in behaviour)? Does
 setting regs 0x71-0x73 change anything (line 1159 still commented)?
 
Result of setting only 0x75 0x76 0x79 0x7c 0x7d (not 0x7f) : 
http://ggastebois.free.fr/lide90_snoop/10_test1.tar

Result of setting 0x71 0x72 0x73 0x75 0x76 0x79 0x7c 0x7d (not 0x7f) :
http://ggastebois.free.fr/lide90_snoop/10_test2.tar

 (I have only little understanding of the actual relative timing and use
 of all clock signals going out to the ccd/afe, so i am guessing and
 doing experiments.)
 
 But this seems to be basically working. Please send your changes leading
 to a usable scan, so i can integrate them.
For now, my code is ugly. I only modified lide60 to lide90. But you can 
find genesys_gl841.c and genesys_devices.c in 
http://ggastebois.free.fr/lide90_snoop/sources

 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???
 The calibration is probably giving widely differing results with
 different starting conditions. It swings between two states. But you
 shouldn't see this after the gl842 did its shading correction. Then, the
 problem is probably overexposure of the ccd cells. Try reducing the
 upper threshold in genesys_gl841.c:4383

 if (avge  2000) {
 expr = (expr * 2000) / avge;
 expg = (expg * 2000) / avge;
 expb = (expb * 2000) / avge;

 Reducing the lower threshold may be needed, too. The current values for
 your scanner are:
 expr: 1235
 expg: 1235
 expb: 675

 No guarantee that this helps at all.
I tryed that (upper threshold to 1500 and lower to 250 and it doesn't 
work. You can find the same test as test2 without the same result on : 
http://ggastebois.free.fr/lide90_snoop/10_test2b.tar (I just make two 
consecutive scanimage without recompiling sane).

One other thing : we can see vertical lines with different contrast on 
result images. What is it ?

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I'm back.
 
 Today I made two tests : one with un commenting line 1159 and adding 
 regs 0x71, 0x72, 0x73, 0x75, 0x76, 0x79, 0x7c, 0x7d, 0x7f in 
 gl841_init_registers.
 Result is a totally black image 
 (http://ggastebois.free.fr/lide90_snoop/04_test1.tar).
 
 The other is with un commenting line 1159 and without adding regs 0x71, 
 0x72, 0x73, 0x75, 0x76, 0x79, 0x7c, 0x7d, 0x7f in gl841_init_registers.
 Result is a totally black image too 
 (http://ggastebois.free.fr/lide90_snoop/04_test2.tar).

What about only setting register 0x7f? that one should do something
without needing to setup reg 0x1a.

I didn't expect reg[0x1a]=0x24 to work without setting the corresponding
clock bit masks. What happens if you leave line 1159 commented and set
regs 0x74-0x7d(my guess: works without changes in behaviour)? Does
setting regs 0x71-0x73 change anything (line 1159 still commented)?

(I have only little understanding of the actual relative timing and use
of all clock signals going out to the ccd/afe, so i am guessing and
doing experiments.)

But this seems to be basically working. Please send your changes leading
to a usable scan, so i can integrate them.

Regards,
  Pierre

 Regards
 Guillaume
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I modified these registers. But the scanner locks writting continiously :
 [genesys] sanei_genesys_read_register (0x41, 0xf4) completed.

 I modified 0x1a=0x24 and 0x1d=0x02 in Genesys_Sensor. In log I see 
 0x1d=0x02 but 0x1a=0x00 ??
 For the missing change of 0x1a: The code block for setting this value
 (along with 0x1b..0x1d, which is then hardcoded to 0x02) is commented
 out, genesys_gl841.c:1159. This is probably the case, because they were
 not needed for my specific scanner.

 I cannot explain the lockup. I'd play around with different sets of
 registers and see if they work. But i guess, register 0x1a is a key to
 get the rest working.

 I will be long for next answer as I take one week holidays !
 I hope you had a nice week holidays.

 Regards,
   Pierre

 regards
 Guillaume

 Pierre Willenbrock a ?crit :
 Hi,

 Guillaume Gastebois schrieb:
 Hello,

 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.

 0x1a was still 0x24. I modified 0x1d which was 0x04 to 0x02. Result is 
 on http://ggastebois.free.fr/lide90_snoop/22_test1.tar.

 I doesn't find where to modify 0x71-0x7f !!!
 Add them to gl841_init_registers.

 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.

 Done, works.

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

 Done.


 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???
 The calibration is probably giving widely differing results with
 different starting conditions. It swings between two states. But you
 shouldn't see this after the gl842 did its shading correction. Then, the
 problem is probably overexposure of the ccd cells. Try reducing the
 upper threshold in genesys_gl841.c:4383

  if (avge  2000) {
  expr = (expr * 2000) / avge;
  expg = (expg * 2000) / avge;
  expb = (expb * 2000) / avge;

 Reducing the lower threshold may be needed, too. The current values for
 your scanner are:
 expr: 1235
 expg: 1235
 expb: 675

 No guarantee that this helps at all.

 Regards
 Guillaume
 Further, we need to figure out a way to get the LEDs go completely dark.
 0x101 is just about half of 675. I will experiment a bit with my
 scanner, to find out if the gl842 can do that.

 Regards,
   Pierre




 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I'm back.

Today I made two tests : one with un commenting line 1159 and adding 
regs 0x71, 0x72, 0x73, 0x75, 0x76, 0x79, 0x7c, 0x7d, 0x7f in 
gl841_init_registers.
Result is a totally black image 
(http://ggastebois.free.fr/lide90_snoop/04_test1.tar).

The other is with un commenting line 1159 and without adding regs 0x71, 
0x72, 0x73, 0x75, 0x76, 0x79, 0x7c, 0x7d, 0x7f in gl841_init_registers.
Result is a totally black image too 
(http://ggastebois.free.fr/lide90_snoop/04_test2.tar).

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I modified these registers. But the scanner locks writting continiously :
 [genesys] sanei_genesys_read_register (0x41, 0xf4) completed.

 I modified 0x1a=0x24 and 0x1d=0x02 in Genesys_Sensor. In log I see 
 0x1d=0x02 but 0x1a=0x00 ??
 
 For the missing change of 0x1a: The code block for setting this value
 (along with 0x1b..0x1d, which is then hardcoded to 0x02) is commented
 out, genesys_gl841.c:1159. This is probably the case, because they were
 not needed for my specific scanner.
 
 I cannot explain the lockup. I'd play around with different sets of
 registers and see if they work. But i guess, register 0x1a is a key to
 get the rest working.
 
 I will be long for next answer as I take one week holidays !
 
 I hope you had a nice week holidays.
 
 Regards,
   Pierre
 
 regards
 Guillaume

 Pierre Willenbrock a ?crit :
 Hi,

 Guillaume Gastebois schrieb:
 Hello,

 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.

 0x1a was still 0x24. I modified 0x1d which was 0x04 to 0x02. Result is 
 on http://ggastebois.free.fr/lide90_snoop/22_test1.tar.

 I doesn't find where to modify 0x71-0x7f !!!
 Add them to gl841_init_registers.

 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.

 Done, works.

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

 Done.


 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???
 The calibration is probably giving widely differing results with
 different starting conditions. It swings between two states. But you
 shouldn't see this after the gl842 did its shading correction. Then, the
 problem is probably overexposure of the ccd cells. Try reducing the
 upper threshold in genesys_gl841.c:4383

   if (avge  2000) {
   expr = (expr * 2000) / avge;
   expg = (expg * 2000) / avge;
   expb = (expb * 2000) / avge;

 Reducing the lower threshold may be needed, too. The current values for
 your scanner are:
 expr: 1235
 expg: 1235
 expb: 675

 No guarantee that this helps at all.

 Regards
 Guillaume
 Further, we need to figure out a way to get the LEDs go completely dark.
 0x101 is just about half of 675. I will experiment a bit with my
 scanner, to find out if the gl842 can do that.

 Regards,
   Pierre


 
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I modified these registers. But the scanner locks writting continiously :
 [genesys] sanei_genesys_read_register (0x41, 0xf4) completed.
 
 I modified 0x1a=0x24 and 0x1d=0x02 in Genesys_Sensor. In log I see 
 0x1d=0x02 but 0x1a=0x00 ??

For the missing change of 0x1a: The code block for setting this value
(along with 0x1b..0x1d, which is then hardcoded to 0x02) is commented
out, genesys_gl841.c:1159. This is probably the case, because they were
not needed for my specific scanner.

I cannot explain the lockup. I'd play around with different sets of
registers and see if they work. But i guess, register 0x1a is a key to
get the rest working.

 I will be long for next answer as I take one week holidays !

I hope you had a nice week holidays.

Regards,
  Pierre

 regards
 Guillaume
 
 Pierre Willenbrock a ?crit :
 Hi,

 Guillaume Gastebois schrieb:
 Hello,

 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.

 0x1a was still 0x24. I modified 0x1d which was 0x04 to 0x02. Result is 
 on http://ggastebois.free.fr/lide90_snoop/22_test1.tar.

 I doesn't find where to modify 0x71-0x7f !!!
 Add them to gl841_init_registers.

 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.

 Done, works.

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

 Done.


 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???
 The calibration is probably giving widely differing results with
 different starting conditions. It swings between two states. But you
 shouldn't see this after the gl842 did its shading correction. Then, the
 problem is probably overexposure of the ccd cells. Try reducing the
 upper threshold in genesys_gl841.c:4383

if (avge  2000) {
expr = (expr * 2000) / avge;
expg = (expg * 2000) / avge;
expb = (expb * 2000) / avge;

 Reducing the lower threshold may be needed, too. The current values for
 your scanner are:
 expr: 1235
 expg: 1235
 expb: 675

 No guarantee that this helps at all.

 Regards
 Guillaume
 Further, we need to figure out a way to get the LEDs go completely dark.
 0x101 is just about half of 675. I will experiment a bit with my
 scanner, to find out if the gl842 can do that.

 Regards,
   Pierre


 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Hi,

Guillaume Gastebois schrieb:
 Hello,
 
 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.

 
 0x1a was still 0x24. I modified 0x1d which was 0x04 to 0x02. Result is 
 on http://ggastebois.free.fr/lide90_snoop/22_test1.tar.
 
 I doesn't find where to modify 0x71-0x7f !!!

Add them to gl841_init_registers.

 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.

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

 
 Done.
 
 
 Another thing : when I make several scan with sane backend and sane 
 command line, I have alternatively brite and dark images !!! Why ???

The calibration is probably giving widely differing results with
different starting conditions. It swings between two states. But you
shouldn't see this after the gl842 did its shading correction. Then, the
problem is probably overexposure of the ccd cells. Try reducing the
upper threshold in genesys_gl841.c:4383

  if (avge  2000) {
  expr = (expr * 2000) / avge;
  expg = (expg * 2000) / avge;
  expb = (expb * 2000) / avge;

Reducing the lower threshold may be needed, too. The current values for
your scanner are:
expr: 1235
expg: 1235
expb: 675

No guarantee that this helps at all.

 Regards
 Guillaume

Further, we need to figure out a way to get the LEDs go completely dark.
0x101 is just about half of 675. I will experiment a bit with my
scanner, to find out if the gl842 can do that.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

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 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

 
 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.
 

0x1a was still 0x24. I modified 0x1d which was 0x04 to 0x02. Result is 
on http://ggastebois.free.fr/lide90_snoop/22_test1.tar.

I doesn't find where to modify 0x71-0x7f !!!

 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.
 

Done, works.

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

Done.

 Regards,
   Pierre
 


Another thing : when I make several scan with sane backend and sane 
command line, I have alternatively brite and dark images !!! Why ???

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

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
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 Yep, I write for (j = 150; j instead of for (i = 150; i.
 Now second set seems good. Result is on : 
 http://ggastebois.free.fr/lide90_snoop/20_test1.tar

 Hi,

 i am sorry, i actually wanted 450, but didn't realize until just now. I
 missed that the calibration dump images are really grayscale images,
 although stored in color pnms. 1 pixel in image is 3 pixels for the
 calibration...

 I hope this fixes that part of the calibration.

 Regards,
   Pierre

 Regards
 Guillaume

 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 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..)

How to do that ? Do you mean a better api adapted to lide 90 or for all genesys
backend ? Do you have some code ?


  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).

OK, interesting program. I'll try it tonight.

One more thing, what are you thinking about output image quality ? Is that
normal with todays calibration or is it another problem ?

Regards
Guillaume

  Regards
  Guillaume

 Regards,
   Pierre

  Pierre Willenbrock a ?crit :
  Guillaume Gastebois schrieb:
  Hello,
 
  Yep, I write for (j = 150; j instead of for (i = 150; i.
  Now second set seems good. Result is on :
  http://ggastebois.free.fr/lide90_snoop/20_test1.tar
 
  Hi,
 
  i am sorry, i actually wanted 450, but didn't realize until just now. I
  missed that the calibration dump images are really grayscale images,
  although stored in color pnms. 1 pixel in image is 3 pixels for the
  calibration...
 
  I hope this fixes that part of the calibration.
 
  Regards,
Pierre
 
  Regards
  Guillaume
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
 
 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..)
 
 How to do that ? Do you mean a better api adapted to lide 90 or for all 
 genesys
 backend ? Do you have some code ?

It is not as bad as i initially thought, the functions for receiving
black/white level information for shading are already available. But
there is some code duplication between genesys.c and
genesys_gl841.c/genesys_gl646.c. All three need to gather black/white
level information, for the various calibrations.

 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).

 OK, interesting program. I'll try it tonight.
 
 One more thing, what are you thinking about output image quality ? Is that
 normal with todays calibration or is it another problem ?

Well, i, for one, can see the impurities of the white inside of the
scanner lid. There are only very faint vertical lines, if at all.
Example attached.

 Regards
 Guillaume
 
 Regards
 Guillaume
 Regards,
   Pierre

 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 Yep, I write for (j = 150; j instead of for (i = 150; i.
 Now second set seems good. Result is on :
 http://ggastebois.free.fr/lide90_snoop/20_test1.tar

 Hi,

 i am sorry, i actually wanted 450, but didn't realize until just now. I
 missed that the calibration dump images are really grayscale images,
 although stored in color pnms. 1 pixel in image is 3 pixels for the
 calibration...

 I hope this fixes that part of the calibration.

 Regards,
   Pierre

 Regards
 Guillaume


 
 
 

-- next part --
A non-text attachment was scrubbed...
Name: canon-lide-35-example.jpg
Type: image/jpeg
Size: 6061 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080221/bebc286c/attachment.jpg
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Yep, I write for (j = 150; j instead of for (i = 150; i.
Now second set seems good. Result is on : 
http://ggastebois.free.fr/lide90_snoop/20_test1.tar

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I modified lines 4596 and 4712 and reenable SCAN_FLAG_DISABLE_LAMP flag.
 Result can be found on : http://ggastebois.free.fr/lide90_snoop/19_test1.tar
 
 Okay, results look good so far:
 [genesys_gl841] gl841_offset_calibration: first set: 191/683,191/482,191/76
 
 but there must be a little bug in the code:
 [genesys_gl841] gl841_offset_calibration: second set:
 0/-1080773208,8/-1212144018,-1080773236/134721688
 
 this very much looks like the variables for the second set are getting
 overwritten/not initialized. Please try to find the problem(misplaced
 brackets perhaps? copy+pasto when calculating the second set?), or send
 the source.
 
 Regards,
   Pierre
 
 Regards
 Guillaume

 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 OK, I'll try this tonight. What is the best : WITH or WITHOUT
 SCAN_FLAG_DISABLE_LAMP ?
 Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
 to get black levels on a white-only calibration area.

 Regards,
   Pierre

 Regards
 Guillaume

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

 test 1 : too bright/too dard = 10/65525 WITH flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test1.tar

 test 2 : too bright/too dard = 10/65525 WITHOUT flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test2.tar

 Not what i expected, although the debug images are looking good.

 Please try to change the first pixel used for minimum calculation to 200
 at about lines 4596 and 4712:
 -  for (i = 0; i  num_pixels; i++)
 +  for (i = 150; i  num_pixels; i++)
   {
 if (dev-model-is_cis)
 val =


 Regards,
   Pierre


 
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 Yep, I write for (j = 150; j instead of for (i = 150; i.
 Now second set seems good. Result is on : 
 http://ggastebois.free.fr/lide90_snoop/20_test1.tar
 

Hi,

i am sorry, i actually wanted 450, but didn't realize until just now. I
missed that the calibration dump images are really grayscale images,
although stored in color pnms. 1 pixel in image is 3 pixels for the
calibration...

I hope this fixes that part of the calibration.

Regards,
  Pierre

 Regards
 Guillaume
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I modified lines 4596 and 4712 and reenable SCAN_FLAG_DISABLE_LAMP flag.
 Result can be found on : http://ggastebois.free.fr/lide90_snoop/19_test1.tar
 Okay, results look good so far:
 [genesys_gl841] gl841_offset_calibration: first set: 191/683,191/482,191/76

 but there must be a little bug in the code:
 [genesys_gl841] gl841_offset_calibration: second set:
 0/-1080773208,8/-1212144018,-1080773236/134721688

 this very much looks like the variables for the second set are getting
 overwritten/not initialized. Please try to find the problem(misplaced
 brackets perhaps? copy+pasto when calculating the second set?), or send
 the source.

 Regards,
   Pierre

 Regards
 Guillaume

 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 OK, I'll try this tonight. What is the best : WITH or WITHOUT
 SCAN_FLAG_DISABLE_LAMP ?
 Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
 to get black levels on a white-only calibration area.

 Regards,
   Pierre

 Regards
 Guillaume

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

 test 1 : too bright/too dard = 10/65525 WITH flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test1.tar

 test 2 : too bright/too dard = 10/65525 WITHOUT flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test2.tar

 Not what i expected, although the debug images are looking good.

 Please try to change the first pixel used for minimum calculation to 200
 at about lines 4596 and 4712:
 -  for (i = 0; i  num_pixels; i++)
 +  for (i = 150; i  num_pixels; i++)
   {
if (dev-model-is_cis)
val =


 Regards,
   Pierre



 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

OK, I'll try this tonight. What is the best : WITH or WITHOUT
SCAN_FLAG_DISABLE_LAMP ?

Regards
Guillaume

Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
  Hello,
 
  I made two tests today :
 
  test 1 : too bright/too dard = 10/65525 WITH flag :
  SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
  http://ggastebois.free.fr/lide90_snoop/18_test1.tar
 
  test 2 : too bright/too dard = 10/65525 WITHOUT flag :
  SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
  http://ggastebois.free.fr/lide90_snoop/18_test2.tar
 

 Not what i expected, although the debug images are looking good.

 Please try to change the first pixel used for minimum calculation to 200
 at about lines 4596 and 4712:
 -  for (i = 0; i  num_pixels; i++)
 +  for (i = 150; i  num_pixels; i++)
   {
 if (dev-model-is_cis)
 val =


 Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 OK, I'll try this tonight. What is the best : WITH or WITHOUT
 SCAN_FLAG_DISABLE_LAMP ?

Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
to get black levels on a white-only calibration area.

Regards,
  Pierre

 
 Regards
 Guillaume
 
 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
 
 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

 test 1 : too bright/too dard = 10/65525 WITH flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test1.tar

 test 2 : too bright/too dard = 10/65525 WITHOUT flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test2.tar

 Not what i expected, although the debug images are looking good.

 Please try to change the first pixel used for minimum calculation to 200
 at about lines 4596 and 4712:
 -  for (i = 0; i  num_pixels; i++)
 +  for (i = 150; i  num_pixels; i++)
   {
if (dev-model-is_cis)
val =


 Regards,
   Pierre

 
 
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I modified lines 4596 and 4712 and reenable SCAN_FLAG_DISABLE_LAMP flag.
Result can be found on : http://ggastebois.free.fr/lide90_snoop/19_test1.tar

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 OK, I'll try this tonight. What is the best : WITH or WITHOUT
 SCAN_FLAG_DISABLE_LAMP ?
 
 Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
 to get black levels on a white-only calibration area.
 
 Regards,
   Pierre
 
 Regards
 Guillaume

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

 test 1 : too bright/too dard = 10/65525 WITH flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test1.tar

 test 2 : too bright/too dard = 10/65525 WITHOUT flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test2.tar

 Not what i expected, although the debug images are looking good.

 Please try to change the first pixel used for minimum calculation to 200
 at about lines 4596 and 4712:
 -  for (i = 0; i  num_pixels; i++)
 +  for (i = 150; i  num_pixels; i++)
   {
   if (dev-model-is_cis)
   val =


 Regards,
   Pierre



 
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I modified lines 4596 and 4712 and reenable SCAN_FLAG_DISABLE_LAMP flag.
 Result can be found on : http://ggastebois.free.fr/lide90_snoop/19_test1.tar

Okay, results look good so far:
[genesys_gl841] gl841_offset_calibration: first set: 191/683,191/482,191/76

but there must be a little bug in the code:
[genesys_gl841] gl841_offset_calibration: second set:
0/-1080773208,8/-1212144018,-1080773236/134721688

this very much looks like the variables for the second set are getting
overwritten/not initialized. Please try to find the problem(misplaced
brackets perhaps? copy+pasto when calculating the second set?), or send
the source.

Regards,
  Pierre

 Regards
 Guillaume
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 OK, I'll try this tonight. What is the best : WITH or WITHOUT
 SCAN_FLAG_DISABLE_LAMP ?
 Not using SCAN_FLAG_DISABLE_LAMP is a bit counter productive when trying
 to get black levels on a white-only calibration area.

 Regards,
   Pierre

 Regards
 Guillaume

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

 test 1 : too bright/too dard = 10/65525 WITH flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test1.tar

 test 2 : too bright/too dard = 10/65525 WITHOUT flag :
 SCAN_FLAG_DISABLE_LAMP. Result can bee found on :
 http://ggastebois.free.fr/lide90_snoop/18_test2.tar

 Not what i expected, although the debug images are looking good.

 Please try to change the first pixel used for minimum calculation to 200
 at about lines 4596 and 4712:
 -  for (i = 0; i  num_pixels; i++)
 +  for (i = 150; i  num_pixels; i++)
   {
  if (dev-model-is_cis)
  val =


 Regards,
   Pierre




 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I try both {0x00, 0x3f, 0x03, 0x26}, and {0x00, 0x3f, 0x00, 0x26},
 you can find result under :
 http://ggastebois.free.fr/lide90_snoop/17_test1.tar
 and http://ggastebois.free.fr/lide90_snoop/17_test2.tar

Looks a lot better. The offset*.pnm actually show a black image,
coarse.pnm is gray. That is good.

I suspect you are still running with the change in thresholds?:
@@ -4545,9 +4546,9 @@
  val =
  first_line[i * 2 * channels + 2 * j + 1] * 256 +
  first_line[i * 2 * channels + 2 * j];
- if (val  10)
+ if (val  1000)
  cmin[j]++;
- if (val  65525)
+ if (val  4)
  cmax[j]++;
  }

Please undo that change. Should give you a nice 2-3-step offset
calibration, that actually works(at least i hope so).

Regarding the output format of the AFE, stay with {0x00, 0x3f, 0x03,
0x26} for now. This does not seem to make any difference, but there are
suspicously many 16 bit words with the binary pattern
 .fgh .fgh (that is, the two middle nibbles share the lower 3
bits). We may be sampling the digital image data at the wrong times. As
the most significant byte seems to come through correctly, this does not
need immediate fixing. (On a second thought, this may affect the offset
calibration. See the thesholds. We'll see.)

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I made two tests today :

test 1 : too bright/too dard = 10/65525 WITH flag : 
SCAN_FLAG_DISABLE_LAMP. Result can bee found on : 
http://ggastebois.free.fr/lide90_snoop/18_test1.tar

test 2 : too bright/too dard = 10/65525 WITHOUT flag : 
SCAN_FLAG_DISABLE_LAMP. Result can bee found on : 
http://ggastebois.free.fr/lide90_snoop/18_test2.tar

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I try both {0x00, 0x3f, 0x03, 0x26}, and {0x00, 0x3f, 0x00, 0x26},
 you can find result under :
 http://ggastebois.free.fr/lide90_snoop/17_test1.tar
 and http://ggastebois.free.fr/lide90_snoop/17_test2.tar
 
 Looks a lot better. The offset*.pnm actually show a black image,
 coarse.pnm is gray. That is good.
 
 I suspect you are still running with the change in thresholds?:
 @@ -4545,9 +4546,9 @@
   val =
   first_line[i * 2 * channels + 2 * j + 1] * 256 +
   first_line[i * 2 * channels + 2 * j];
 - if (val  10)
 + if (val  1000)
   cmin[j]++;
 - if (val  65525)
 + if (val  4)
   cmax[j]++;
   }
 
 Please undo that change. Should give you a nice 2-3-step offset
 calibration, that actually works(at least i hope so).
 
 Regarding the output format of the AFE, stay with {0x00, 0x3f, 0x03,
 0x26} for now. This does not seem to make any difference, but there are
 suspicously many 16 bit words with the binary pattern
  .fgh .fgh (that is, the two middle nibbles share the lower 3
 bits). We may be sampling the digital image data at the wrong times. As
 the most significant byte seems to come through correctly, this does not
 need immediate fixing. (On a second thought, this may affect the offset
 calibration. See the thesholds. We'll see.)
 
 Regards,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 You can find the result of this test here :
 
 http://ggastebois.free.fr/lide90_snoop/no_shading_2bright_2dark.tar
 
 The calibration is about 25s long.
 Resulting image is bad (as befor).
 

Please try with bit 4+5 of frontend setup register 1 set to 3:
{0x00, 0x3f, 0x03, 0x26},
...

And, while you are at it, try if you can get setup register 2, bits 0+1
set to 0 to work. that may affect the position of the data, so you may
need to fiddle with gl842 registers 0x52-0x57.

 Regards
 Guillaume

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I try both {0x00, 0x3f, 0x03, 0x26}, and {0x00, 0x3f, 0x00, 0x26},
you can find result under :
http://ggastebois.free.fr/lide90_snoop/17_test1.tar
and http://ggastebois.free.fr/lide90_snoop/17_test2.tar

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 You can find the result of this test here :

 http://ggastebois.free.fr/lide90_snoop/no_shading_2bright_2dark.tar

 The calibration is about 25s long.
 Resulting image is bad (as befor).

 
 Please try with bit 4+5 of frontend setup register 1 set to 3:
 {0x00, 0x3f, 0x03, 0x26},
 ...
 
 And, while you are at it, try if you can get setup register 2, bits 0+1
 set to 0 to work. that may affect the position of the data, so you may
 need to fiddle with gl842 registers 0x52-0x57.
 
 Regards
 Guillaume
 
 Regards,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

You can find the result of this test here :

http://ggastebois.free.fr/lide90_snoop/no_shading_2bright_2dark.tar

The calibration is about 25s long.
Resulting image is bad (as befor).

Regards
Guillaume


Pierre Willenbrock a ?crit :
 Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Hello,

 You can find all of that on : 
 http://ggastebois.free.fr/lide90_snoop/no_shading.tar

 What seems strange in calibration ?

 The minimum/maximum values retrieved from the scans do not scale with
 the offset values, but in a rather random manner. The calibration
 expects a linear relationship.

 Regards,
   Pierre

 
 Hi,
 
 the raw offset calibration data looks horrible. Too bright and noisy.
 Please change the too bright/too dark thresholds for
 gl841_offset_calibration in genesys_gl841.c like this:
 
 @@ -4545,9 +4546,9 @@
   val =
   first_line[i * 2 * channels + 2 * j + 1] * 256 +
   first_line[i * 2 * channels + 2 * j];
 - if (val  10)
 + if (val  1000)
   cmin[j]++;
 - if (val  65525)
 + if (val  4)
   cmax[j]++;
   }
 
 Send/Put online the debug files offset*.pnm, and the
 gl841_offset_calibration: acceptable offsets:  lines from the debug
 output(Or the whole set, whichever is more convenient ;-)).
 
 Regards,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Hello,

 You can find all of that on : 
 http://ggastebois.free.fr/lide90_snoop/no_shading.tar

 What seems strange in calibration ?

 
 The minimum/maximum values retrieved from the scans do not scale with
 the offset values, but in a rather random manner. The calibration
 expects a linear relationship.
 
 Regards,
   Pierre
 

Hi,

the raw offset calibration data looks horrible. Too bright and noisy.
Please change the too bright/too dark thresholds for
gl841_offset_calibration in genesys_gl841.c like this:

@@ -4545,9 +4546,9 @@
  val =
  first_line[i * 2 * channels + 2 * j + 1] * 256 +
  first_line[i * 2 * channels + 2 * j];
- if (val  10)
+ if (val  1000)
  cmin[j]++;
- if (val  65525)
+ if (val  4)
  cmax[j]++;
  }

Send/Put online the debug files offset*.pnm, and the
gl841_offset_calibration: acceptable offsets:  lines from the debug
output(Or the whole set, whichever is more convenient ;-)).

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

You can find all of that on : 
http://ggastebois.free.fr/lide90_snoop/no_shading.tar

What seems strange in calibration ?

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 So. I tryed your patch with and without shading calibration :

 with shading : same as bevor but calibration is now 4s long (see 
 http://ggastebois.free.fr/lide90_snoop/no_shading.jpg and 
 http://ggastebois.free.fr/lide90_snoop/no_shading.txt)

 without shading : image with some vertical lines (but ve can see the 
 dinausore). Calibration is 4s long (see 
 http://ggastebois.free.fr/lide90_snoop/shading.jpg and 
 http://ggastebois.free.fr/lide90_snoop/shading.txt)

 
 Calibration results look strange. when running scanimage with the two
 debug environment variables set to 255, you get a set of calibration
 files(*.pnm). Please put them together with the error-output of the run
 into some kind of compressed archive(compressed .tar or .zip). Put them
 online or send them here(but i doubt they are  37k).
 
 Thanks,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 You can find all of that on : 
 http://ggastebois.free.fr/lide90_snoop/no_shading.tar
 
 What seems strange in calibration ?
 

The minimum/maximum values retrieved from the scans do not scale with
the offset values, but in a rather random manner. The calibration
expects a linear relationship.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Hello,

 I see that reg[2] was like 0x07. So INVOP was still set !!!
 I comment out offset_calibration in genesys_flatbed_calibration, set 
 reg[2] to 0x03, and I get a black image with a gray vertical line in the 
 middle !!!
 I try to reenable offset_calibration and I get : 
 http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_invop_0.jpg
 In the central vertical line we can see a piece of my dinosause not 
 reverted !!! I think this works. And good news : the frontend seems to 
 be (or to be compatible) with a wolfson wm8199.

 If you remember, this gray line is on the vertical of the small black 
 piece (in calibration area). So calibration is better with black area !!

 
 hmm. the shading calibration currently needs some black to work. But
 good news. Now, where did i put that alternative offset_calibration code...
 

obviously, in cvs, while thinking i'd only put the power-mode changes
in.. The needed change is a one liner..

This should compile, but i don't know if it works. The shading
calibration should still be commented out. offset_calibration,
gain_calibration and led_calibration might work.

Regards,
  Pierre
-- next part --
A non-text attachment was scrubbed...
Name: offset-calib.patch
Type: text/x-patch
Size: 599 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080213/25da0826/attachment.bin
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

OK, I'll try it tonight.
How do I cleanly remove shading_calibration ?

Regards
Guillaume

Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Pierre Willenbrock schrieb:
  Guillaume Gastebois schrieb:
  Hello,
 
  I see that reg[2] was like 0x07. So INVOP was still set !!!
  I comment out offset_calibration in genesys_flatbed_calibration, set
  reg[2] to 0x03, and I get a black image with a gray vertical line in the
  middle !!!
  I try to reenable offset_calibration and I get :
  http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_invop_0.jpg
  In the central vertical line we can see a piece of my dinosause not
  reverted !!! I think this works. And good news : the frontend seems to
  be (or to be compatible) with a wolfson wm8199.
 
  If you remember, this gray line is on the vertical of the small black
  piece (in calibration area). So calibration is better with black area !!
 
 
  hmm. the shading calibration currently needs some black to work. But
  good news. Now, where did i put that alternative offset_calibration code...
 

 obviously, in cvs, while thinking i'd only put the power-mode changes
 in.. The needed change is a one liner..

 This should compile, but i don't know if it works. The shading
 calibration should still be commented out. offset_calibration,
 gain_calibration and led_calibration might work.

 Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 OK, I'll try it tonight.
 How do I cleanly remove shading_calibration ?

The code for the actual calibration is in genesys.c, line 3362:
  /* shading calibration */
to line 3414, before
  /* send gamma tables if needed */

 
 Regards
 Guillaume
 

[sane-devel] Canon LiDE 90

[s...@tsleg.com]

Hi.

I've something quite good (not inverted ;) ) ...

But I did not commented those lines, but removed 
GENESYS_FLAG_DARK_WHITE_CALIBRATION in canon_lide_60_model structure, 
and set register[2] to 0x03
(See files : http://home.tsleg.com/saneLiDE90/saturated/ )

http://home.tsleg.com/saneLiDE90/saturated/image.jpg
Colors seems over saturated ... Do you know where can be the problem ?
And my grey source image has colors ... 
http://home.tsleg.com/saneLiDE90/saturated/image_greySource.jpg




Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
   
 Hello,

 OK, I'll try it tonight.
 How do I cleanly remove shading_calibration ?
 

 The code for the actual calibration is in genesys.c, line 3362:
   /* shading calibration */
 to line 3414, before
   /* send gamma tables if needed */

   
 Regards
 Guillaume

 


   

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

So. I tryed your patch with and without shading calibration :

with shading : same as bevor but calibration is now 4s long (see 
http://ggastebois.free.fr/lide90_snoop/no_shading.jpg and 
http://ggastebois.free.fr/lide90_snoop/no_shading.txt)

without shading : image with some vertical lines (but ve can see the 
dinausore). Calibration is 4s long (see 
http://ggastebois.free.fr/lide90_snoop/shading.jpg and 
http://ggastebois.free.fr/lide90_snoop/shading.txt)

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Hello,

 I see that reg[2] was like 0x07. So INVOP was still set !!!
 I comment out offset_calibration in genesys_flatbed_calibration, set 
 reg[2] to 0x03, and I get a black image with a gray vertical line in the 
 middle !!!
 I try to reenable offset_calibration and I get : 
 http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_invop_0.jpg
 In the central vertical line we can see a piece of my dinosause not 
 reverted !!! I think this works. And good news : the frontend seems to 
 be (or to be compatible) with a wolfson wm8199.

 If you remember, this gray line is on the vertical of the small black 
 piece (in calibration area). So calibration is better with black area !!

 hmm. the shading calibration currently needs some black to work. But
 good news. Now, where did i put that alternative offset_calibration code...

 
 obviously, in cvs, while thinking i'd only put the power-mode changes
 in.. The needed change is a one liner..
 
 This should compile, but i don't know if it works. The shading
 calibration should still be commented out. offset_calibration,
 gain_calibration and led_calibration might work.
 
 Regards,
   Pierre
 

[sane-devel] Canon LiDE 90

[s...@tsleg.com]

Hi,

I've made some progress ...

I changed :
 /* CANOLIDE35 */
  {1200,
/*TODO: find a good reason for keeping all three following variables*/
   87,/*(black) */
   87,/* (dummy) */
   0,/* (startxoffset) */
   10400,/*sensor_pixels */
   210,
   200,

By :
 /* CANOLIDE35 */
  {600,
/*TODO: find a good reason for keeping all three following variables*/
   87,/*(black) */
   87,/* (dummy) */
   0,/* (startxoffset) */
   10400,/*sensor_pixels */
   210,
   200,

And used the gpo values :
  /* CANONLIDE35 */
  {
   {0x38, 0x80}
   ,
{0x7f, 0xe0}

It's no so bad ... (but image is always inverted ...)
To have the white led, in color mode of scanimage, it's ok.

scanimage -d  --mode Color  image.pnm

PS : I need to be root ... do you know what to do to avoid it ?

Concerning scan borders, we must change scan area (not best, but better) :
 SANE_FIX (9.),/* Start of scan area in mm  (x) */
  SANE_FIX (7.7),/* Start of scan area in mm (y) */
  SANE_FIX (218.0),/* Size of scan area in mm (x) */
  SANE_FIX (297.0),/* Size of scan area in mm (y) */




Guillaume Gastebois a ?crit :
 Hello,

 I modified registers 10-1d with :

 {0x04, 0xd3, 0x04, 0xd3, 0x02, 0xa3, 0x20, 0x06, 0x00, 0xff, 0x24, 0x00, 
 0x00, 0x04},
   
Where do I set this ? (which parameter of which struct ?)

Thanks again for your help.


PS : Reading your comments, I guess you're french ;)
Bonne soir?e ;)

 and now the led is really white (red green and blue by moving eyes).

 Led calibration seems to be good.

 But calibration is always 60s long.
 I need help.
 Thanks

 Regards
 Guillaume

 Pierre Willenbrock a ?crit :
   
 Hi Guillaume,

 Guillaume Gastebois schrieb:
 
 Hello,

 Why calibration is so long (~50/60s) ?
   
 It is probably failing. Should take about 3-5 seconds. Look at the logs,
 the calculated averages and calibration are dumped there.

 
 What are /* Start of white strip in mm (y) */ and /* Start of black mark 
 in mm (x) */ in genesys_devices.c ?
   
 Those are configuration values for calibration steps. I don't know if
 any of these are currently used or if the values are hardcoded.

 I think the start-of-black-mark is used to detect the beginning of the
 document area for some gl646 scanners. The start-of-white-strip was once
 used in shading calibration. Currently, the shading calibration is setup
 for a calibration area looking like this:

 home position
 +
 !   black area
 +
 !   white area
 +

 The border between black area and white area is autodetected per pixel,
 as the border is usually not straight.

 You scanner seems to offer only a white area, so we will need to do
 shading calibration differently. My current idea is this:
 * always gather data on a white area
 * for black data, reduce the led exposure time to the minimum(0x101,
 those registers cannot be set to 0. per byte.).
 * for white data, use the normal exposure times
 I tried something like this for offset calibration, to see if there is
 any difference between white area+0x101 exposure time and black
 area+normal exposure time. There was no difference in the final images,
 and i think the resulting calibration was the same as well.

 
 Regarding the log file you said :
 W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
 W  ! 0x2b ! 0x028 ! pga gain rgb
 But on debug, I see that these two registers are never written.
   
 0x23 and 0x2b are merely convenience registers. Writing to 0x23 and 0x2b
 is equivalent to a write to each of 0x20-0x22 and 0x28-0x2a. For
 cis-sensors, there is only one channel used, so we could get away with
 only two registers writes(for the correct channel or 0x23/0x2b), but
 this won't work for ccd-sensors.

 
 Another thing : when scaning in color the leds are blue 
   
 I'd expect a shade of white, perhaps blueish. my scanner does a
 magentaish white. You may also see the single colors when quickly moving
 your eyes relatively to the scanner.

 Regards,
   Pierre


 

   

[sane-devel] Canon LiDE 90

[s...@tsleg.com]

sane at tsleg.com a ?crit :

 Where do I set this ? (which parameter of which struct ?)
   
Sorry ... I found where to set this.

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I inverted colors with gimp. Sorry I forget this operation.


Selon postmaster postmaster at tsleg.com:

 Hi,


 How did you get this one :
 http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_comment.jpg ??

 Colors are not inverted ...


 Guillaume Gastebois a ?crit :
  Hello,
 
  I modified registers 10-1d with :
 
  {0x04, 0xd3, 0x04, 0xd3, 0x02, 0xa3, 0x20, 0x06, 0x00, 0xff, 0x24, 0x00,
  0x00, 0x04},
 
  and now the led is really white (red green and blue by moving eyes).
 
  Led calibration seems to be good.
 
  But calibration is always 60s long.
  I need help.
  Thanks
 
  Regards
  Guillaume
 
  Pierre Willenbrock a ?crit :
 
  Hi Guillaume,
 
  Guillaume Gastebois schrieb:
 
  Hello,
 
  Why calibration is so long (~50/60s) ?
 
  It is probably failing. Should take about 3-5 seconds. Look at the logs,
  the calculated averages and calibration are dumped there.
 
 
  What are /* Start of white strip in mm (y) */ and /* Start of black mark
  in mm (x) */ in genesys_devices.c ?
 
  Those are configuration values for calibration steps. I don't know if
  any of these are currently used or if the values are hardcoded.
 
  I think the start-of-black-mark is used to detect the beginning of the
  document area for some gl646 scanners. The start-of-white-strip was once
  used in shading calibration. Currently, the shading calibration is setup
  for a calibration area looking like this:
 
  home position
  +
  !   black area
  +
  !   white area
  +
 
  The border between black area and white area is autodetected per pixel,
  as the border is usually not straight.
 
  You scanner seems to offer only a white area, so we will need to do
  shading calibration differently. My current idea is this:
  * always gather data on a white area
  * for black data, reduce the led exposure time to the minimum(0x101,
  those registers cannot be set to 0. per byte.).
  * for white data, use the normal exposure times
  I tried something like this for offset calibration, to see if there is
  any difference between white area+0x101 exposure time and black
  area+normal exposure time. There was no difference in the final images,
  and i think the resulting calibration was the same as well.
 
 
  Regarding the log file you said :
  W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
  W  ! 0x2b ! 0x028 ! pga gain rgb
  But on debug, I see that these two registers are never written.
 
  0x23 and 0x2b are merely convenience registers. Writing to 0x23 and 0x2b
  is equivalent to a write to each of 0x20-0x22 and 0x28-0x2a. For
  cis-sensors, there is only one channel used, so we could get away with
  only two registers writes(for the correct channel or 0x23/0x2b), but
  this won't work for ccd-sensors.
 
 
  Another thing : when scaning in color the leds are blue 
 
  I'd expect a shade of white, perhaps blueish. my scanner does a
  magentaish white. You may also see the single colors when quickly moving
  your eyes relatively to the scanner.
 
  Regards,
Pierre
 
 
 
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I modified registers 10-1d with :
 
 {0x04, 0xd3, 0x04, 0xd3, 0x02, 0xa3, 0x20, 0x06, 0x00, 0xff, 0x24, 0x00, 
 0x00, 0x04},
 
 and now the led is really white (red green and blue by moving eyes).
 
 Led calibration seems to be good.
 
 But calibration is always 60s long.

http://ggastebois.free.fr/lide90_snoop/scanimage.log
says you have offset_calibration enabled. that cannot work currently.
offset_calibration fiddles with the Frontend offset parameters and will
make the following calibration steps fail. Comment that out in
genesys_flatbed_calibration for now.

Apart from that, please try to toggle the INVOP bit, that is
bit2(counting from 0) of Setup Register 2. This may fix the inverted
image. Looking at the Block diagram of the WM8199, the calibration may
still need to be changed if INVOP=1, but it is worth a try.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I see that reg[2] was like 0x07. So INVOP was still set !!!
I comment out offset_calibration in genesys_flatbed_calibration, set 
reg[2] to 0x03, and I get a black image with a gray vertical line in the 
middle !!!
I try to reenable offset_calibration and I get : 
http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_invop_0.jpg
In the central vertical line we can see a piece of my dinosause not 
reverted !!! I think this works. And good news : the frontend seems to 
be (or to be compatible) with a wolfson wm8199.

If you remember, this gray line is on the vertical of the small black 
piece (in calibration area). So calibration is better with black area !!

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I modified registers 10-1d with :

 {0x04, 0xd3, 0x04, 0xd3, 0x02, 0xa3, 0x20, 0x06, 0x00, 0xff, 0x24, 0x00, 
 0x00, 0x04},

 and now the led is really white (red green and blue by moving eyes).

 Led calibration seems to be good.

 But calibration is always 60s long.
 
 http://ggastebois.free.fr/lide90_snoop/scanimage.log
 says you have offset_calibration enabled. that cannot work currently.
 offset_calibration fiddles with the Frontend offset parameters and will
 make the following calibration steps fail. Comment that out in
 genesys_flatbed_calibration for now.
 
 Apart from that, please try to toggle the INVOP bit, that is
 bit2(counting from 0) of Setup Register 2. This may fix the inverted
 image. Looking at the Block diagram of the WM8199, the calibration may
 still need to be changed if INVOP=1, but it is worth a try.
 
 Regards,
   Pierre
 
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I see that reg[2] was like 0x07. So INVOP was still set !!!
 I comment out offset_calibration in genesys_flatbed_calibration, set 
 reg[2] to 0x03, and I get a black image with a gray vertical line in the 
 middle !!!
 I try to reenable offset_calibration and I get : 
 http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_invop_0.jpg
 In the central vertical line we can see a piece of my dinosause not 
 reverted !!! I think this works. And good news : the frontend seems to 
 be (or to be compatible) with a wolfson wm8199.
 
 If you remember, this gray line is on the vertical of the small black 
 piece (in calibration area). So calibration is better with black area !!
 

hmm. the shading calibration currently needs some black to work. But
good news. Now, where did i put that alternative offset_calibration code...

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I modified registers 10-1d with :

{0x04, 0xd3, 0x04, 0xd3, 0x02, 0xa3, 0x20, 0x06, 0x00, 0xff, 0x24, 0x00, 
0x00, 0x04},

and now the led is really white (red green and blue by moving eyes).

Led calibration seems to be good.

But calibration is always 60s long.
I need help.
Thanks

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Hi Guillaume,
 
 Guillaume Gastebois schrieb:
 Hello,

 Why calibration is so long (~50/60s) ?
 
 It is probably failing. Should take about 3-5 seconds. Look at the logs,
 the calculated averages and calibration are dumped there.
 
 What are /* Start of white strip in mm (y) */ and /* Start of black mark 
 in mm (x) */ in genesys_devices.c ?
 
 Those are configuration values for calibration steps. I don't know if
 any of these are currently used or if the values are hardcoded.
 
 I think the start-of-black-mark is used to detect the beginning of the
 document area for some gl646 scanners. The start-of-white-strip was once
 used in shading calibration. Currently, the shading calibration is setup
 for a calibration area looking like this:
 
 home position
 +
 !   black area
 +
 !   white area
 +
 
 The border between black area and white area is autodetected per pixel,
 as the border is usually not straight.
 
 You scanner seems to offer only a white area, so we will need to do
 shading calibration differently. My current idea is this:
 * always gather data on a white area
 * for black data, reduce the led exposure time to the minimum(0x101,
 those registers cannot be set to 0. per byte.).
 * for white data, use the normal exposure times
 I tried something like this for offset calibration, to see if there is
 any difference between white area+0x101 exposure time and black
 area+normal exposure time. There was no difference in the final images,
 and i think the resulting calibration was the same as well.
 
 Regarding the log file you said :
 W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
 W  ! 0x2b ! 0x028 ! pga gain rgb
 But on debug, I see that these two registers are never written.
 
 0x23 and 0x2b are merely convenience registers. Writing to 0x23 and 0x2b
 is equivalent to a write to each of 0x20-0x22 and 0x28-0x2a. For
 cis-sensors, there is only one channel used, so we could get away with
 only two registers writes(for the correct channel or 0x23/0x2b), but
 this won't work for ccd-sensors.
 
 Another thing : when scaning in color the leds are blue 
 
 I'd expect a shade of white, perhaps blueish. my scanner does a
 magentaish white. You may also see the single colors when quickly moving
 your eyes relatively to the scanner.
 
 Regards,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[s...@tsleg.com]

Hi guys,

I gess I have an answer of my question ;)
 I just bought a Canon LiDE 90 and can't make it work ... I will try to 
 make a backend, but I wanted to be sure that nobody was doing it ...

 Is there anybody working on it ?
   
Do you think I could help for anything ? Can I download anywhere what 
you did until now ?

I'd really like to make my new scan to work ;)

Thanks for your job.

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Pierre Willenbrock a ?crit :
 Hi Guillaume,
 
 Guillaume Gastebois schrieb:
 Hello,

 Why calibration is so long (~50/60s) ?
 
 It is probably failing. Should take about 3-5 seconds. Look at the logs,
 the calculated averages and calibration are dumped there.
 
 What are /* Start of white strip in mm (y) */ and /* Start of black mark 
 in mm (x) */ in genesys_devices.c ?
 
 Those are configuration values for calibration steps. I don't know if
 any of these are currently used or if the values are hardcoded.
 
 I think the start-of-black-mark is used to detect the beginning of the
 document area for some gl646 scanners. The start-of-white-strip was once
 used in shading calibration. Currently, the shading calibration is setup
 for a calibration area looking like this:
 
 home position
 +
 !   black area
 +
 !   white area
 +
 
 The border between black area and white area is autodetected per pixel,
 as the border is usually not straight.
 
 You scanner seems to offer only a white area, so we will need to do
 shading calibration differently. My current idea is this:
 * always gather data on a white area
 * for black data, reduce the led exposure time to the minimum(0x101,
 those registers cannot be set to 0. per byte.).
 * for white data, use the normal exposure times
 I tried something like this for offset calibration, to see if there is
 any difference between white area+0x101 exposure time and black
 area+normal exposure time. There was no difference in the final images,
 and i think the resulting calibration was the same as well.
 
 Regarding the log file you said :
 W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
 W  ! 0x2b ! 0x028 ! pga gain rgb
 But on debug, I see that these two registers are never written.
 
 0x23 and 0x2b are merely convenience registers. Writing to 0x23 and 0x2b
 is equivalent to a write to each of 0x20-0x22 and 0x28-0x2a. For
 cis-sensors, there is only one channel used, so we could get away with
 only two registers writes(for the correct channel or 0x23/0x2b), but
 this won't work for ccd-sensors.
 
 Another thing : when scaning in color the leds are blue 
 
 I'd expect a shade of white, perhaps blueish. my scanner does a
 magentaish white. You may also see the single colors when quickly moving
 your eyes relatively to the scanner.
 

Yes, I know that. But I only see blue and green. No red.

 Regards,
   Pierre
 

Regards
Guillaume

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I forget in my last mail (I'm hill today. It's not good for 
concentration...) : You can find a scanimage log on : 
http://ggastebois.free.fr/lide90_snoop/scanimage.log.

Regards
Guillaume

Pierre Willenbrock a ?crit :
 Hi Guillaume,
 
 Guillaume Gastebois schrieb:
 Hello,

 Why calibration is so long (~50/60s) ?
 
 It is probably failing. Should take about 3-5 seconds. Look at the logs,
 the calculated averages and calibration are dumped there.
 
 What are /* Start of white strip in mm (y) */ and /* Start of black mark 
 in mm (x) */ in genesys_devices.c ?
 
 Those are configuration values for calibration steps. I don't know if
 any of these are currently used or if the values are hardcoded.
 
 I think the start-of-black-mark is used to detect the beginning of the
 document area for some gl646 scanners. The start-of-white-strip was once
 used in shading calibration. Currently, the shading calibration is setup
 for a calibration area looking like this:
 
 home position
 +
 !   black area
 +
 !   white area
 +
 
 The border between black area and white area is autodetected per pixel,
 as the border is usually not straight.
 
 You scanner seems to offer only a white area, so we will need to do
 shading calibration differently. My current idea is this:
 * always gather data on a white area
 * for black data, reduce the led exposure time to the minimum(0x101,
 those registers cannot be set to 0. per byte.).
 * for white data, use the normal exposure times
 I tried something like this for offset calibration, to see if there is
 any difference between white area+0x101 exposure time and black
 area+normal exposure time. There was no difference in the final images,
 and i think the resulting calibration was the same as well.
 
 Regarding the log file you said :
 W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
 W  ! 0x2b ! 0x028 ! pga gain rgb
 But on debug, I see that these two registers are never written.
 
 0x23 and 0x2b are merely convenience registers. Writing to 0x23 and 0x2b
 is equivalent to a write to each of 0x20-0x22 and 0x28-0x2a. For
 cis-sensors, there is only one channel used, so we could get away with
 only two registers writes(for the correct channel or 0x23/0x2b), but
 this won't work for ccd-sensors.
 
 Another thing : when scaning in color the leds are blue 
 
 I'd expect a shade of white, perhaps blueish. my scanner does a
 magentaish white. You may also see the single colors when quickly moving
 your eyes relatively to the scanner.
 
 Regards,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

You can find my modified files for LiDE90 on : 
http://ggastebois.free.fr/lide90_snoop/sources/

With them you will bee able to scan images (very poor quality) in 
reversed video (???) and with a calibration during 60s (!!!)

Regards
Guillaume

sane at tsleg.com a ?crit :
 Hi guys,
 
 I gess I have an answer of my question ;)
 I just bought a Canon LiDE 90 and can't make it work ... I will try to 
 make a backend, but I wanted to be sure that nobody was doing it ...

 Is there anybody working on it ?
   
 Do you think I could help for anything ? Can I download anywhere what 
 you did until now ?
 
 I'd really like to make my new scan to work ;)
 
 Thanks for your job.
 
 

[sane-devel] Canon LiDE 90

[René Rebe]

On Saturday 09 February 2008 18:59:47 sane at tsleg.com wrote:
 Hi all,
 
 I just bought a Canon LiDE 90 and can't make it work ... I will try to 
 make a backend, but I wanted to be sure that nobody was doing it ...
 
 Is there anybody working on it ?

Yes, just look into the archive, e.g. even of the last days.

Yours,

-- 
  Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Why calibration is so long (~50/60s) ?

What are /* Start of white strip in mm (y) */ and /* Start of black mark 
in mm (x) */ in genesys_devices.c ?

Regarding the log file you said :
W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
W  ! 0x2b ! 0x028 ! pga gain rgb
But on debug, I see that these two registers are never written.

Another thing : when scaning in color the leds are blue 

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 I need a little bit more informations befor testing (sorry for my poor 
 knowledge
 in scanner)

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 I don't know why the image colors are reversed, but it may be worth
 trying to flip the sign bits in Genesys_Frontend. If that does nothing,
 we need to handle that in code(or i am missing some setting of the gl841).
 The other thing you have seen is the half-resolution mode, used for
 greater speed when doing lower(i.E. not full) resolutions.

 How do you explain yhat with half resolution the image seems to be grayscale 
 and
 without it seems to be lineart ?
 
 If you look closely, you see that the image is not exactly lineart. When
 doing half resolution, the sensitivity of the scanner sensor changes,
 and thus needs a different afe setup. That should be handled gracefully
 by the offset/gain calibration, once those are working.
 
 Subsidary question : what is the small white (perhaps black) rectangle
 in the middle up off page (for calibration) ?
 That may be a small metal clamp holding the glass or the calibration
 strip. That is the black(i.E. white) part at the very top.

 Under this small rectangle I have a vertical more clear line(same height). 
 Is it
 because I need to tweek calibration area (without this small rectangle) ?

 To summarize, it is a good idea to have bit 4 on, bit 5 is the half
 resolution switch. I'd put 0x10 into the 0x6c gpio register.

 As for the calibration area, you will need to change some code:
 * comment out genesys_gl841.c:4220:(line numbers may differ)
   status = gl841_feed(dev, 280);/*feed to white strip. canon lide 35 only.*/
 * the same for genesys_gl841.c:4821:
   status = gl841_feed(dev, 280);/*feed to white strip. canon lide 35 only.*/

When I comment out these lines the result is very bad (sample 
http://ggastebois.free.fr/lide90_snoop/toto_10_0_0_comment.jpg)


 then you can try what happens when you turn on the led_calibration and
 the coarse_gain_calibration. offset_calibration needs a bit more
 changes. i think i am having the code needed lying around somewhere.
 essentially, the offset calibration needs to be done with leds off.
 the shading calibration does need even more changes.

 Where to find led_calibration, coarse_gain_calibration ? How to turn them on 
 ?
 For personnal information : what is shading calibration 
 
 They are called by genesys_flatbed_calibration, i think i requested to
 comment them out earlier.

OK, sorry, I did that some days ago. My last mail and sample images were 
WITH led_calibration and coarse_gain_calibration.

 
 There are three things to calibrate for:
 1) the mapping from sensor voltages to numbers, to not lose color space
 by clipping lower brightness to 0 or higher brightness to 65535.
 ideally, you don't ever see 0 or 65535 from the afe. This is mainly the
 job of offset/gain calibration, but the led-exposure is a factor to this.
 2) the color intensities relative to each other. We try to get each
 colored LED to lead to similar voltages in the sensor during its
 exposure. This is calibrated by led_calibration
 3) Variations between the sensor cells. each sensor cell has it's own
 sensitivity and black voltage, so there needs to be a
 per-pixel-correction. This is done by shading_calibration.
 
 Additionally, the shading_calibration is by-color, so this is the place
 where we map each color channel to the correct range, as the
 led_calibration is not that exact.
 
 Additionally, if you can't get the afe to switch the sign, you need to
 do that in the calibration functions(i.E. 65535-value).

 Only in calibration function ?
 
 For now, that should be enough. We are not interested in the actual
 output image, yet.
 
 Regards,
   Pierre
 
 Regards
 Guillaume

 Regards,
   Pierre

 
 
 
Regards
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Hi Guillaume,

Guillaume Gastebois schrieb:
 Hello,
 
 Why calibration is so long (~50/60s) ?

It is probably failing. Should take about 3-5 seconds. Look at the logs,
the calculated averages and calibration are dumped there.

 What are /* Start of white strip in mm (y) */ and /* Start of black mark 
 in mm (x) */ in genesys_devices.c ?

Those are configuration values for calibration steps. I don't know if
any of these are currently used or if the values are hardcoded.

I think the start-of-black-mark is used to detect the beginning of the
document area for some gl646 scanners. The start-of-white-strip was once
used in shading calibration. Currently, the shading calibration is setup
for a calibration area looking like this:

home position
+
!   black area
+
!   white area
+

The border between black area and white area is autodetected per pixel,
as the border is usually not straight.

You scanner seems to offer only a white area, so we will need to do
shading calibration differently. My current idea is this:
* always gather data on a white area
* for black data, reduce the led exposure time to the minimum(0x101,
those registers cannot be set to 0. per byte.).
* for white data, use the normal exposure times
I tried something like this for offset calibration, to see if there is
any difference between white area+0x101 exposure time and black
area+normal exposure time. There was no difference in the final images,
and i think the resulting calibration was the same as well.

 Regarding the log file you said :
 W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
 W  ! 0x2b ! 0x028 ! pga gain rgb
 But on debug, I see that these two registers are never written.

0x23 and 0x2b are merely convenience registers. Writing to 0x23 and 0x2b
is equivalent to a write to each of 0x20-0x22 and 0x28-0x2a. For
cis-sensors, there is only one channel used, so we could get away with
only two registers writes(for the correct channel or 0x23/0x2b), but
this won't work for ccd-sensors.

 Another thing : when scaning in color the leds are blue 

I'd expect a shade of white, perhaps blueish. my scanner does a
magentaish white. You may also see the single colors when quickly moving
your eyes relatively to the scanner.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I need a little bit more informations befor testing (sorry for my poor 
 knowledge
 in scanner)
 
 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:
 
 I don't know why the image colors are reversed, but it may be worth
 trying to flip the sign bits in Genesys_Frontend. If that does nothing,
 we need to handle that in code(or i am missing some setting of the gl841).
 The other thing you have seen is the half-resolution mode, used for
 greater speed when doing lower(i.E. not full) resolutions.

 
 How do you explain yhat with half resolution the image seems to be grayscale 
 and
 without it seems to be lineart ?

If you look closely, you see that the image is not exactly lineart. When
doing half resolution, the sensitivity of the scanner sensor changes,
and thus needs a different afe setup. That should be handled gracefully
by the offset/gain calibration, once those are working.

 Subsidary question : what is the small white (perhaps black) rectangle
 in the middle up off page (for calibration) ?
 That may be a small metal clamp holding the glass or the calibration
 strip. That is the black(i.E. white) part at the very top.

 Under this small rectangle I have a vertical more clear line(same height). Is 
 it
 because I need to tweek calibration area (without this small rectangle) ?
 
 To summarize, it is a good idea to have bit 4 on, bit 5 is the half
 resolution switch. I'd put 0x10 into the 0x6c gpio register.

 As for the calibration area, you will need to change some code:
 * comment out genesys_gl841.c:4220:(line numbers may differ)
   status = gl841_feed(dev, 280);/*feed to white strip. canon lide 35 only.*/
 * the same for genesys_gl841.c:4821:
   status = gl841_feed(dev, 280);/*feed to white strip. canon lide 35 only.*/

 then you can try what happens when you turn on the led_calibration and
 the coarse_gain_calibration. offset_calibration needs a bit more
 changes. i think i am having the code needed lying around somewhere.
 essentially, the offset calibration needs to be done with leds off.
 the shading calibration does need even more changes.

 Where to find led_calibration, coarse_gain_calibration ? How to turn them on ?
 For personnal information : what is shading calibration 

They are called by genesys_flatbed_calibration, i think i requested to
comment them out earlier.

There are three things to calibrate for:
1) the mapping from sensor voltages to numbers, to not lose color space
by clipping lower brightness to 0 or higher brightness to 65535.
ideally, you don't ever see 0 or 65535 from the afe. This is mainly the
job of offset/gain calibration, but the led-exposure is a factor to this.
2) the color intensities relative to each other. We try to get each
colored LED to lead to similar voltages in the sensor during its
exposure. This is calibrated by led_calibration
3) Variations between the sensor cells. each sensor cell has it's own
sensitivity and black voltage, so there needs to be a
per-pixel-correction. This is done by shading_calibration.

Additionally, the shading_calibration is by-color, so this is the place
where we map each color channel to the correct range, as the
led_calibration is not that exact.

 
 Additionally, if you can't get the afe to switch the sign, you need to
 do that in the calibration functions(i.E. 65535-value).

 
 Only in calibration function ?

For now, that should be enough. We are not interested in the actual
output image, yet.

Regards,
  Pierre

 
 Regards
 Guillaume
 
 Regards,
   Pierre

 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 It's a little bit better with these values.
 In Genesys_Sensor I have :
 regs_0x08_0x0b : {0x00, 0x21, 0x00, 0x00}
 regs_0x10_0x1d : {0x02, 0x8b, 0x02, 0x8b, 0x02, 0x8b, 0x20, 0x06, 0x00,
 0xff, 0x24, 0x00, 0x00, 0x04}
 regs_0x52_0x5e : {0x02, 0x04, 0x02, 0x04, 0x02, 0x04, 0x0a, 0x71, 0x55,
 0x00, 0x00, 0x20, 0x41}
 
 looks good so far(very few of these can be found in the log after my
 scripts processed them(bug in my scripts), but then they must be okay
 when you are able to scan)
 
 In Genesys_Gpo I have :
 {0x02, 0x80}{0x7f, 0xe0}
 
 i found these differing settings in your log for register 0x6c:
 0x00
 0x02
 0x0a
 0x0e
 0x10
 0x12
 0x18
 0x1a
 0x38
 0x3a
 0x3e
 0x3c
 
I tryed all these values :
02 : revert video image with a lot of vertical lines
0a : revert video image with a lot of vertical lines and motor doesn't 
stop at the end of the page
0e, 3e : don't know home position anymore
10, 12, 18, 1a : revert video image seems to be in black and white (no 
grayscale) but no more vertical images
38, 3a : revert video image in grayscale but take only half of the 
screen in height.
3c : motor make noise but don't move

You can find sample at :
http://ggastebois.free.fr/lide90_snoop/toto_18_0_0.jpg
http://ggastebois.free.fr/lide90_snoop/toto_38_0_0.jpg

these two image are original (just saved in jpg) with x y offset set to 0.

How can we explain that images are in reverse video and that with 38 and 
3a the image takes only half the place ?

Subsidary question : what is the small white (perhaps black) rectangle 
in the middle up off page (for calibration) ?

Regards
Guillaume

 it may be interesting to find out what the effects of these are.
 
 and now in Genesys_Frontend :
 {{0x00, 0x2f, 0x07, 0x26}
, {0x00, 0x00, 0x00}
, {0x50, 0x50, 0x50}
, {0x28, 0x28, 0x28}
, {0x0d, 0x00, 0x00}
}
 
 Looks good.
 
 Are these value acceptable regarding my log
 (http://ggastebois.free.fr/lide90_snoop/UsbSnoop_a4_200dpi.log) ?

 I very appreciate your help.

 Regards
 Guillaume

 P.S : attached a sample image with my values.
 
 Regarding the image: is this with x|y_offset == 0? and are the
 horizontal bright lines original?
 
 Regards,
   Pierre
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 OK, but via which register is it programmed. I find nothing in GL842
 datasheet
 for frontend.

 regards
 Guillaume

 the analog frontend is programmed through the serial interface accessed
 by address registers 0x50(FERDA)/0x51(FEWRA) and data registers
 0x46/0x47(FERDDATA)/0x3a/0x3b(FEWRDATA).

 I find this sequence in your log:

 R/W ! addr ! data  ! WM8199 register
 +--+---+-
  W  ! 0x04 ! 0x000 ! reset
  R  ! 0x07 ! 0x041 ! revision number, ==0x41
  W  ! 0x04 ! 0x000 ! reset
  W  ! 0x01 ! 0x02f ! Setup reg 1: mode4==0, pgafs=2, selpd=1, mono=1,
 cds=1, en=1
  W  ! 0x02 ! 0x007 ! Setup reg 2: del=0, rlcdacrng=0, 0=0, vrlcext=0,
 invop=1, muxop=3
  W  ! 0x03 ! 0x026 ! Setup reg 3: chan=0, cdsref=2, rlcv=6
  W  ! 0x06 ! 0x00d ! Setup reg 4: fm=0, intm=0, rlcint=1, fme=1,
 acycnrlc=0, linebyline=1
  W  ! 0x08 ! 0x000 ! Setup reg 5: 0=0, posnneg=0, vdel=0, vsmpdet=0
  W  ! 0x20 ! 0x050 ! dac value red(offset value)
  W  ! 0x21 ! 0x050 ! dac value green(offset value)
  W  ! 0x22 ! 0x050 ! dac value blue(offset value)
  W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
  W  ! 0x28 ! 0x028 ! pga gain red(0x28 is a factor of 0.85)
  W  ! 0x29 ! 0x028 ! pga gain green
  W  ! 0x2a ! 0x028 ! pga gain blue
  W  ! 0x2b ! 0x028 ! pga gain rgb


 all WM81xx(at least where datasheets are available) share a similar
 register layout, with revision 0x41 at address 7. writing to the rgb
 variant of pga gain/dac value results in writes to all the color
 specific registers, so it is not needed.

 So, you have in Genesys_Frontend: reg[1]=0x2f, reg[2]=0x07, reg[3]=0x26,
 reg2[0]=0x0d, reg2[1]=0x00, the rest of reg/reg2 =0, all sign[x]=0,
 offset[x]=0x50, gain[x]=0x28.

 this does not match anything currently in genesys_devices.c. Just add
 one entry to the Wolfson array, #define a DAC_ to 7 in genesys_low.h
 and put that in your Genesys_Model.

 The gain/offset setting should be good for led calibration and will be
 replaced by gain/offset calibration.

 After that, get a scan of the calibration area(the area under the
 housing at the parking position). For this, put 0 into the x_offset and
 y_offset in your Genesys_Model. If this turns out to be similar to the
 calibration area of the lide 50, led/offset/gain-calibration should work
 with only minor changes.

 Regards,
   Pierre


 

 
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

 It's a little bit better with these values.
 In Genesys_Sensor I have :
 regs_0x08_0x0b : {0x00, 0x21, 0x00, 0x00}
 regs_0x10_0x1d : {0x02, 0x8b, 0x02, 0x8b, 0x02, 0x8b, 0x20, 0x06, 0x00,
 0xff, 0x24, 0x00, 0x00, 0x04}
 regs_0x52_0x5e : {0x02, 0x04, 0x02, 0x04, 0x02, 0x04, 0x0a, 0x71, 0x55,
 0x00, 0x00, 0x20, 0x41}
 looks good so far(very few of these can be found in the log after my
 scripts processed them(bug in my scripts), but then they must be okay
 when you are able to scan)

 In Genesys_Gpo I have :
 {0x02, 0x80}{0x7f, 0xe0}
 i found these differing settings in your log for register 0x6c:
 0x00
 0x02
 0x0a
 0x0e
 0x10
 0x12
 0x18
 0x1a
 0x38
 0x3a
 0x3e
 0x3c

 I tryed all these values :
 02 : revert video image with a lot of vertical lines
 0a : revert video image with a lot of vertical lines and motor doesn't 
 stop at the end of the page
 0e, 3e : don't know home position anymore
 10, 12, 18, 1a : revert video image seems to be in black and white (no 
 grayscale) but no more vertical images
 38, 3a : revert video image in grayscale but take only half of the 
 screen in height.
 3c : motor make noise but don't move
 
 You can find sample at :
 http://ggastebois.free.fr/lide90_snoop/toto_18_0_0.jpg
 http://ggastebois.free.fr/lide90_snoop/toto_38_0_0.jpg
 
 these two image are original (just saved in jpg) with x y offset set to 0.
 
 How can we explain that images are in reverse video and that with 38 and 
 3a the image takes only half the place ?

I don't know why the image colors are reversed, but it may be worth
trying to flip the sign bits in Genesys_Frontend. If that does nothing,
we need to handle that in code(or i am missing some setting of the gl841).
The other thing you have seen is the half-resolution mode, used for
greater speed when doing lower(i.E. not full) resolutions.

 Subsidary question : what is the small white (perhaps black) rectangle 
 in the middle up off page (for calibration) ?

That may be a small metal clamp holding the glass or the calibration
strip. That is the black(i.E. white) part at the very top.

To summarize, it is a good idea to have bit 4 on, bit 5 is the half
resolution switch. I'd put 0x10 into the 0x6c gpio register.

As for the calibration area, you will need to change some code:
* comment out genesys_gl841.c:4220:(line numbers may differ)
  status = gl841_feed(dev, 280);/*feed to white strip. canon lide 35 only.*/
* the same for genesys_gl841.c:4821:
  status = gl841_feed(dev, 280);/*feed to white strip. canon lide 35 only.*/

then you can try what happens when you turn on the led_calibration and
the coarse_gain_calibration. offset_calibration needs a bit more
changes. i think i am having the code needed lying around somewhere.
essentially, the offset calibration needs to be done with leds off.
the shading calibration does need even more changes.

Additionally, if you can't get the afe to switch the sign, you need to
do that in the calibration functions(i.E. 65535-value).

Regards,
  Pierre

 
 Regards
 Guillaume
 
 it may be interesting to find out what the effects of these are.

 and now in Genesys_Frontend :
 {{0x00, 0x2f, 0x07, 0x26}
, {0x00, 0x00, 0x00}
, {0x50, 0x50, 0x50}
, {0x28, 0x28, 0x28}
, {0x0d, 0x00, 0x00}
}
 Looks good.

 Are these value acceptable regarding my log
 (http://ggastebois.free.fr/lide90_snoop/UsbSnoop_a4_200dpi.log) ?

 I very appreciate your help.

 Regards
 Guillaume

 P.S : attached a sample image with my values.
 Regarding the image: is this with x|y_offset == 0? and are the
 horizontal bright lines original?

 Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 It's a little bit better with these values.
 In Genesys_Sensor I have :
 regs_0x08_0x0b : {0x00, 0x21, 0x00, 0x00}
 regs_0x10_0x1d : {0x02, 0x8b, 0x02, 0x8b, 0x02, 0x8b, 0x20, 0x06, 0x00,
 0xff, 0x24, 0x00, 0x00, 0x04}
 regs_0x52_0x5e : {0x02, 0x04, 0x02, 0x04, 0x02, 0x04, 0x0a, 0x71, 0x55,
 0x00, 0x00, 0x20, 0x41}

looks good so far(very few of these can be found in the log after my
scripts processed them(bug in my scripts), but then they must be okay
when you are able to scan)

 In Genesys_Gpo I have :
 {0x02, 0x80}{0x7f, 0xe0}

i found these differing settings in your log for register 0x6c:
0x00
0x02
0x0a
0x0e
0x10
0x12
0x18
0x1a
0x38
0x3a
0x3e
0x3c

it may be interesting to find out what the effects of these are.

 and now in Genesys_Frontend :
 {{0x00, 0x2f, 0x07, 0x26}
, {0x00, 0x00, 0x00}
, {0x50, 0x50, 0x50}
, {0x28, 0x28, 0x28}
, {0x0d, 0x00, 0x00}
}

Looks good.

 
 Are these value acceptable regarding my log
 (http://ggastebois.free.fr/lide90_snoop/UsbSnoop_a4_200dpi.log) ?
 
 I very appreciate your help.
 
 Regards
 Guillaume
 
 P.S : attached a sample image with my values.

Regarding the image: is this with x|y_offset == 0? and are the
horizontal bright lines original?

Regards,
  Pierre

 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 OK, but via which register is it programmed. I find nothing in GL842
 datasheet
 for frontend.

 regards
 Guillaume


 the analog frontend is programmed through the serial interface accessed
 by address registers 0x50(FERDA)/0x51(FEWRA) and data registers
 0x46/0x47(FERDDATA)/0x3a/0x3b(FEWRDATA).

 I find this sequence in your log:

 R/W ! addr ! data  ! WM8199 register
 +--+---+-
  W  ! 0x04 ! 0x000 ! reset
  R  ! 0x07 ! 0x041 ! revision number, ==0x41
  W  ! 0x04 ! 0x000 ! reset
  W  ! 0x01 ! 0x02f ! Setup reg 1: mode4==0, pgafs=2, selpd=1, mono=1,
 cds=1, en=1
  W  ! 0x02 ! 0x007 ! Setup reg 2: del=0, rlcdacrng=0, 0=0, vrlcext=0,
 invop=1, muxop=3
  W  ! 0x03 ! 0x026 ! Setup reg 3: chan=0, cdsref=2, rlcv=6
  W  ! 0x06 ! 0x00d ! Setup reg 4: fm=0, intm=0, rlcint=1, fme=1,
 acycnrlc=0, linebyline=1
  W  ! 0x08 ! 0x000 ! Setup reg 5: 0=0, posnneg=0, vdel=0, vsmpdet=0
  W  ! 0x20 ! 0x050 ! dac value red(offset value)
  W  ! 0x21 ! 0x050 ! dac value green(offset value)
  W  ! 0x22 ! 0x050 ! dac value blue(offset value)
  W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
  W  ! 0x28 ! 0x028 ! pga gain red(0x28 is a factor of 0.85)
  W  ! 0x29 ! 0x028 ! pga gain green
  W  ! 0x2a ! 0x028 ! pga gain blue
  W  ! 0x2b ! 0x028 ! pga gain rgb


 all WM81xx(at least where datasheets are available) share a similar
 register layout, with revision 0x41 at address 7. writing to the rgb
 variant of pga gain/dac value results in writes to all the color
 specific registers, so it is not needed.

 So, you have in Genesys_Frontend: reg[1]=0x2f, reg[2]=0x07, reg[3]=0x26,
 reg2[0]=0x0d, reg2[1]=0x00, the rest of reg/reg2 =0, all sign[x]=0,
 offset[x]=0x50, gain[x]=0x28.

 this does not match anything currently in genesys_devices.c. Just add
 one entry to the Wolfson array, #define a DAC_ to 7 in genesys_low.h
 and put that in your Genesys_Model.

 The gain/offset setting should be good for led calibration and will be
 replaced by gain/offset calibration.

 After that, get a scan of the calibration area(the area under the
 housing at the parking position). For this, put 0 into the x_offset and
 y_offset in your Genesys_Model. If this turns out to be similar to the
 calibration area of the lide 50, led/offset/gain-calibration should work
 with only minor changes.

 Regards,
   Pierre


 
 
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

It's a little bit better with these values.
In Genesys_Sensor I have :
regs_0x08_0x0b : {0x00, 0x21, 0x00, 0x00}
regs_0x10_0x1d : {0x02, 0x8b, 0x02, 0x8b, 0x02, 0x8b, 0x20, 0x06, 0x00, 
0xff, 0x24, 0x00, 0x00, 0x04}
regs_0x52_0x5e : {0x02, 0x04, 0x02, 0x04, 0x02, 0x04, 0x0a, 0x71, 0x55, 
0x00, 0x00, 0x20, 0x41}

In Genesys_Gpo I have :
{0x02, 0x80}{0x7f, 0xe0}

and now in Genesys_Frontend :
{{0x00, 0x2f, 0x07, 0x26}
, {0x00, 0x00, 0x00}
, {0x50, 0x50, 0x50}
, {0x28, 0x28, 0x28}
, {0x0d, 0x00, 0x00}
}

Are these value acceptable regarding my log 
(http://ggastebois.free.fr/lide90_snoop/UsbSnoop_a4_200dpi.log) ?

I very appreciate your help.

Regards
Guillaume

P.S : attached a sample image with my values.

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 OK, but via which register is it programmed. I find nothing in GL842 
 datasheet
 for frontend.

 regards
 Guillaume

 
 the analog frontend is programmed through the serial interface accessed
 by address registers 0x50(FERDA)/0x51(FEWRA) and data registers
 0x46/0x47(FERDDATA)/0x3a/0x3b(FEWRDATA).
 
 I find this sequence in your log:
 
 R/W ! addr ! data  ! WM8199 register
 +--+---+-
  W  ! 0x04 ! 0x000 ! reset
  R  ! 0x07 ! 0x041 ! revision number, ==0x41
  W  ! 0x04 ! 0x000 ! reset
  W  ! 0x01 ! 0x02f ! Setup reg 1: mode4==0, pgafs=2, selpd=1, mono=1,
 cds=1, en=1
  W  ! 0x02 ! 0x007 ! Setup reg 2: del=0, rlcdacrng=0, 0=0, vrlcext=0,
 invop=1, muxop=3
  W  ! 0x03 ! 0x026 ! Setup reg 3: chan=0, cdsref=2, rlcv=6
  W  ! 0x06 ! 0x00d ! Setup reg 4: fm=0, intm=0, rlcint=1, fme=1,
 acycnrlc=0, linebyline=1
  W  ! 0x08 ! 0x000 ! Setup reg 5: 0=0, posnneg=0, vdel=0, vsmpdet=0
  W  ! 0x20 ! 0x050 ! dac value red(offset value)
  W  ! 0x21 ! 0x050 ! dac value green(offset value)
  W  ! 0x22 ! 0x050 ! dac value blue(offset value)
  W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
  W  ! 0x28 ! 0x028 ! pga gain red(0x28 is a factor of 0.85)
  W  ! 0x29 ! 0x028 ! pga gain green
  W  ! 0x2a ! 0x028 ! pga gain blue
  W  ! 0x2b ! 0x028 ! pga gain rgb
 
 
 all WM81xx(at least where datasheets are available) share a similar
 register layout, with revision 0x41 at address 7. writing to the rgb
 variant of pga gain/dac value results in writes to all the color
 specific registers, so it is not needed.
 
 So, you have in Genesys_Frontend: reg[1]=0x2f, reg[2]=0x07, reg[3]=0x26,
 reg2[0]=0x0d, reg2[1]=0x00, the rest of reg/reg2 =0, all sign[x]=0,
 offset[x]=0x50, gain[x]=0x28.
 
 this does not match anything currently in genesys_devices.c. Just add
 one entry to the Wolfson array, #define a DAC_ to 7 in genesys_low.h
 and put that in your Genesys_Model.
 
 The gain/offset setting should be good for led calibration and will be
 replaced by gain/offset calibration.
 
 After that, get a scan of the calibration area(the area under the
 housing at the parking position). For this, put 0 into the x_offset and
 y_offset in your Genesys_Model. If this turns out to be similar to the
 calibration area of the lide 50, led/offset/gain-calibration should work
 with only minor changes.
 
 Regards,
   Pierre
 
 
-- next part --
A non-text attachment was scrubbed...
Name: toto.jpg
Type: image/jpeg
Size: 14210 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080204/32c0a175/attachment.jpg
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

OK, but via which register is it programmed. I find nothing in GL842 datasheet
for frontend.

regards
Guillaume

Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
  Hello,
 
  OK,
  I open my LiDE 90 (very hard not all to destroy...).
  I find these IC's :
 
  GL842 (Genesys well known scanner chip)
  GLT44016P (SO40 RAM)
  BU6574 (TSSOP20 )
  VHC175 (TSSOP16 quad flip flop)
  VHC08 (TSSOP16 quad and)
  LB1940 (TSSOP20 constant current driver)
  LM324 (SO14 quad op amp)
  1733 (TO-263 regularor)
 
  Appart the BU6574 (I dont find what it is) I dont find any analog
  frontend. Is it possible that this chip is located with leds (seems very
  hard to open.)
 

 I don't know where the analog frontend may be found. There are arguments
 for both positions.

 The BU6574 has enough pins for the job. Did you look at the back of the
 pcb?

 In the documentation i found for one cis sensor, the glassy sensor
 itself contains just the ccd row and the leds. There may be a small pcb
 on the sensor bar, carrying the analog frontend.

 But you really don't need to look for the chip and possibly destroy your
 scanner on the way.. Let's first try to figure out how it is configured
 from an usb log.

 Regards,
   Pierre

[sane-devel] Canon LiDE 90

[Gerhard Jaeger]

On Friday 01 February 2008 09:18:20 Guillaume Gastebois wrote:
 OK, but via which register is it programmed. I find nothing in GL842 datasheet
 for frontend.
 
check for register 0x04
Layout:
Bit 7   |Bit 6  |Bit 5 Bit 4 |Bit 3 Bit 2 |Bit 1 Bit 0
LINEART |BITSET |AFEMOD[1:0] |FILTER[1:0] |FESET[1:0] 

HTH
Gerhard

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 OK, but via which register is it programmed. I find nothing in GL842 datasheet
 for frontend.
 
 regards
 Guillaume
 

the analog frontend is programmed through the serial interface accessed
by address registers 0x50(FERDA)/0x51(FEWRA) and data registers
0x46/0x47(FERDDATA)/0x3a/0x3b(FEWRDATA).

I find this sequence in your log:

R/W ! addr ! data  ! WM8199 register
+--+---+-
 W  ! 0x04 ! 0x000 ! reset
 R  ! 0x07 ! 0x041 ! revision number, ==0x41
 W  ! 0x04 ! 0x000 ! reset
 W  ! 0x01 ! 0x02f ! Setup reg 1: mode4==0, pgafs=2, selpd=1, mono=1,
cds=1, en=1
 W  ! 0x02 ! 0x007 ! Setup reg 2: del=0, rlcdacrng=0, 0=0, vrlcext=0,
invop=1, muxop=3
 W  ! 0x03 ! 0x026 ! Setup reg 3: chan=0, cdsref=2, rlcv=6
 W  ! 0x06 ! 0x00d ! Setup reg 4: fm=0, intm=0, rlcint=1, fme=1,
acycnrlc=0, linebyline=1
 W  ! 0x08 ! 0x000 ! Setup reg 5: 0=0, posnneg=0, vdel=0, vsmpdet=0
 W  ! 0x20 ! 0x050 ! dac value red(offset value)
 W  ! 0x21 ! 0x050 ! dac value green(offset value)
 W  ! 0x22 ! 0x050 ! dac value blue(offset value)
 W  ! 0x23 ! 0x050 ! dac value rgb(offset value)
 W  ! 0x28 ! 0x028 ! pga gain red(0x28 is a factor of 0.85)
 W  ! 0x29 ! 0x028 ! pga gain green
 W  ! 0x2a ! 0x028 ! pga gain blue
 W  ! 0x2b ! 0x028 ! pga gain rgb


all WM81xx(at least where datasheets are available) share a similar
register layout, with revision 0x41 at address 7. writing to the rgb
variant of pga gain/dac value results in writes to all the color
specific registers, so it is not needed.

So, you have in Genesys_Frontend: reg[1]=0x2f, reg[2]=0x07, reg[3]=0x26,
reg2[0]=0x0d, reg2[1]=0x00, the rest of reg/reg2 =0, all sign[x]=0,
offset[x]=0x50, gain[x]=0x28.

this does not match anything currently in genesys_devices.c. Just add
one entry to the Wolfson array, #define a DAC_ to 7 in genesys_low.h
and put that in your Genesys_Model.

The gain/offset setting should be good for led calibration and will be
replaced by gain/offset calibration.

After that, get a scan of the calibration area(the area under the
housing at the parking position). For this, put 0 into the x_offset and
y_offset in your Genesys_Model. If this turns out to be similar to the
calibration area of the lide 50, led/offset/gain-calibration should work
with only minor changes.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

OK,
I open my LiDE 90 (very hard not all to destroy...).
I find these IC's :

GL842 (Genesys well known scanner chip)
GLT44016P (SO40 RAM)
BU6574 (TSSOP20 )
VHC175 (TSSOP16 quad flip flop)
VHC08 (TSSOP16 quad and)
LB1940 (TSSOP20 constant current driver)
LM324 (SO14 quad op amp)
1733 (TO-263 regularor)

Appart the BU6574 (I dont find what it is) I dont find any analog 
frontend. Is it possible that this chip is located with leds (seems very 
hard to open.)

regards
Guillaume

Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
  But you can ignore led-calibration for now, that is not essential when
  debugging the backend. Just make sure the exposure settings in
  Genesys_Sensor.regs_0x10_0x1d are good, for example from an usb log the
  last register write to 0x10-0x15 before receiving actual scanned data.
  If those stay all zero, the rgb-leds in your scanner are very probably
  not controlled using the rgb-led-control-feature of the gl84x.
  
  You can disable led calibration by commenting out the code in
  genesys_flatbed_calibration. Offset/Gain calibration can be commented
  out when the values in Genesys_Frontend are good, Shading calibration
  can be disabled when you add OPTICAL_FLAG_DISABLE_SHADING to the flags
  for gl841_init_optical_regs_scan. When shading calibration is disabled,
  you get vertical stripes, the others lead to too dark/bright r/g/b 
  channels.
  
  Things that may be missing:
  * leds need to be controlled correctly
  * cis-sensor needs to get the correct clock signals(line toggle+pixel
clock, half-resolution signal is optional for now)
  * the analog frontend registers need to be setup correctly in
Genesys_Frontend
  * the readout position in the data stream from the analog frontend may
need tweaking(registers 0x52,0x53)
  
  When that is done, you should be able to get an image from your
  scanner, although calibration may be lacking.
  
  Regards,
Pierre

 OK, i see some image (very far to end result...). But can you explain to 
 me how to know the correct values for genesys_frontend 
 These parameter have big influence on resulting image.

 
 genesys_frontend contains the settings for the analog frontend.
 
 the canon lide 35/40/50 seem to be all using the wm8199(afair) or a
 compatible chip, so that datasheet may be helpful.
 
 Datasheets for the wolfson analog frontends can be found on their website:
 http://www.wolfsonmicro.com/productListings/imaging_sensor_adcs/
 
 gl841_set_fe and the calibration functions are currently setup to handle
 a wm8199.
 
 The reg, reg2 and sign entries need to be obtained from an usb log. I
 don't know the actual register mapping, but it should be easy to figure
 that out from gl841_set_fe.
 
 gain and offset will be calibrated by one of the calibration functions.
 The values depend heavily on the LED and Sensor characteristics. For
 now, when the LED exposure time is constant, you can get away with
 constant values.
 
 There seems to be no way to find the exact analog frontend chip without
 looking at the pcb, but that is hopefully not needed.
 
 Simplified, you get the result of this equation from the analog
 frontend(The datasheet has the details):
 
 v: proportional to input voltage from sensor
 o: offset(not necessarily the value from the register)
 g: gain-factor(not necessarily the value from the register)
 d: digital output value
 
 d = (o + v) * g
 
 The behaviour of the sensor can be described by this equation:
 
 i: proportional to the light intensity, which is proportional to led
 exposure time and shade on your original
 v_o: offset voltage
 s: sensitivity of sensor(voltage per intensity)
 
 v = v_o + i * s
 
 The offset/gain calibration optimizes offset and gain such that maximum
 and minimum v fall in the range between maximum and minimum d, but
 trying to maximize the range used in d(this requires at least one led
 exposure time to be setup reasonably).
 
 The LED calibration tries to get all LED colors to result in a similar
 value into the analog frontend, by adjusting the exposure time(this
 requires analog frontend offset/gain values to be setup reasonably).  
 
 
 Sorry for the lengthy mail, but i hope the information is helpful.
 
 Regards,
   Pierre
 
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 OK,
 I open my LiDE 90 (very hard not all to destroy...).
 I find these IC's :
 
   GL842 (Genesys well known scanner chip)
   GLT44016P (SO40 RAM)
   BU6574 (TSSOP20 )
   VHC175 (TSSOP16 quad flip flop)
   VHC08 (TSSOP16 quad and)
   LB1940 (TSSOP20 constant current driver)
   LM324 (SO14 quad op amp)
   1733 (TO-263 regularor)
 
 Appart the BU6574 (I dont find what it is) I dont find any analog 
 frontend. Is it possible that this chip is located with leds (seems very 
 hard to open.)
 

I don't know where the analog frontend may be found. There are arguments
for both positions.

The BU6574 has enough pins for the job. Did you look at the back of the
pcb?

In the documentation i found for one cis sensor, the glassy sensor
itself contains just the ccd row and the leds. There may be a small pcb
on the sensor bar, carrying the analog frontend.

But you really don't need to look for the chip and possibly destroy your
scanner on the way.. Let's first try to figure out how it is configured
from an usb log.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

 But you can ignore led-calibration for now, that is not essential when
 debugging the backend. Just make sure the exposure settings in
 Genesys_Sensor.regs_0x10_0x1d are good, for example from an usb log the
 last register write to 0x10-0x15 before receiving actual scanned data.
 If those stay all zero, the rgb-leds in your scanner are very probably
 not controlled using the rgb-led-control-feature of the gl84x.
 
 You can disable led calibration by commenting out the code in
 genesys_flatbed_calibration. Offset/Gain calibration can be commented
 out when the values in Genesys_Frontend are good, Shading calibration
 can be disabled when you add OPTICAL_FLAG_DISABLE_SHADING to the flags
 for gl841_init_optical_regs_scan. When shading calibration is disabled,
 you get vertical stripes, the others lead to too dark/bright r/g/b 
 channels.
 
 Things that may be missing:
 * leds need to be controlled correctly
 * cis-sensor needs to get the correct clock signals(line toggle+pixel
   clock, half-resolution signal is optional for now)
 * the analog frontend registers need to be setup correctly in
   Genesys_Frontend
 * the readout position in the data stream from the analog frontend may
   need tweaking(registers 0x52,0x53)
 
 When that is done, you should be able to get an image from your
 scanner, although calibration may be lacking.
 
 Regards,
   Pierre

OK, i see some image (very far to end result...). But can you explain to 
me how to know the correct values for genesys_frontend 
These parameter have big influence on resulting image.

Thank you.
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
  But you can ignore led-calibration for now, that is not essential when
  debugging the backend. Just make sure the exposure settings in
  Genesys_Sensor.regs_0x10_0x1d are good, for example from an usb log the
  last register write to 0x10-0x15 before receiving actual scanned data.
  If those stay all zero, the rgb-leds in your scanner are very probably
  not controlled using the rgb-led-control-feature of the gl84x.
  
  You can disable led calibration by commenting out the code in
  genesys_flatbed_calibration. Offset/Gain calibration can be commented
  out when the values in Genesys_Frontend are good, Shading calibration
  can be disabled when you add OPTICAL_FLAG_DISABLE_SHADING to the flags
  for gl841_init_optical_regs_scan. When shading calibration is disabled,
  you get vertical stripes, the others lead to too dark/bright r/g/b 
  channels.
  
  Things that may be missing:
  * leds need to be controlled correctly
  * cis-sensor needs to get the correct clock signals(line toggle+pixel
clock, half-resolution signal is optional for now)
  * the analog frontend registers need to be setup correctly in
Genesys_Frontend
  * the readout position in the data stream from the analog frontend may
need tweaking(registers 0x52,0x53)
  
  When that is done, you should be able to get an image from your
  scanner, although calibration may be lacking.
  
  Regards,
Pierre
 
 OK, i see some image (very far to end result...). But can you explain to 
 me how to know the correct values for genesys_frontend 
 These parameter have big influence on resulting image.
 

genesys_frontend contains the settings for the analog frontend.

the canon lide 35/40/50 seem to be all using the wm8199(afair) or a
compatible chip, so that datasheet may be helpful.

Datasheets for the wolfson analog frontends can be found on their website:
http://www.wolfsonmicro.com/productListings/imaging_sensor_adcs/

gl841_set_fe and the calibration functions are currently setup to handle
a wm8199.

The reg, reg2 and sign entries need to be obtained from an usb log. I
don't know the actual register mapping, but it should be easy to figure
that out from gl841_set_fe.

gain and offset will be calibrated by one of the calibration functions.
The values depend heavily on the LED and Sensor characteristics. For
now, when the LED exposure time is constant, you can get away with
constant values.

There seems to be no way to find the exact analog frontend chip without
looking at the pcb, but that is hopefully not needed.

Simplified, you get the result of this equation from the analog
frontend(The datasheet has the details):

v: proportional to input voltage from sensor
o: offset(not necessarily the value from the register)
g: gain-factor(not necessarily the value from the register)
d: digital output value

d = (o + v) * g

The behaviour of the sensor can be described by this equation:

i: proportional to the light intensity, which is proportional to led
exposure time and shade on your original
v_o: offset voltage
s: sensitivity of sensor(voltage per intensity)

v = v_o + i * s

The offset/gain calibration optimizes offset and gain such that maximum
and minimum v fall in the range between maximum and minimum d, but
trying to maximize the range used in d(this requires at least one led
exposure time to be setup reasonably).

The LED calibration tries to get all LED colors to result in a similar
value into the analog frontend, by adjusting the exposure time(this
requires analog frontend offset/gain values to be setup reasonably).


Sorry for the lengthy mail, but i hope the information is helpful.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Thank you Pierre.
I did all what you do : commenting the code in 
genesys_flatbed_calibration (Offset/Gain calibration commented out too), 
added OPTICAL_FLAG_DISABLE_SHADING to the flags in 
gl841_init_optical_regs_scan

analog frontend is so :
{0x00, 0x21, 0x00, 0x00},
{0x02, 0x8b, 0x02, 0x8b, 0x02, 0x8b, 0x20, 0x06, 0x00, 0xff,
 0x24, 0x00, 0x00, 0x04},
{0x02, 0x04,
 0x02, 0x04, 0x02, 0x04,
 0x0a, 0x71,
 0x55,
 0x00, 0x00, 0x20, 0x41}

I can now see my dinosaure ! See picture attached (colored dinosaure on 
a white page). It's far from perfect !

 Guillaume Gastebois schrieb:
  Hello,
 
  OK, my motor moves !
 
 Cool.
 
 
  But, someting doesn't work during initialisation : I get floating point
  error !
 
  I modified genesys_gl841.c for instrumentation and genesys_devices.c
  (genesys_sensor section) in accordance to my windows usb snoop log (see
  attacement).
 
  SANE_DEBUG_GENESYS_GL841=255 scanimage
  -device-name=genesys:libusb:001:066  toto.pnm ends with :
 
 (please use both SANE_DEBUG_GENESYS_GL841=255 and
 SANE_DEBUG_GENESYS=255, the device specific code calls back into the
 unspecific code)
 
 
  [genesys_gl841] reg[0x86] = 0x00
  [genesys_gl841] reg[0x87] = 0x00
  [genesys_gl841] gl841_bulk_write_register: wrote 104 registers
  [genesys_gl841] gl841_led_calibration: starting first line reading
  [genesys_gl841] gl841_begin_scan
  [genesys_gl841] gl841_bulk_write_register (elems = 4)
  [genesys_gl841] reg[0x03] = 0x5f
  [genesys_gl841] reg[0x01] = 0x81
  [genesys_gl841] reg[0x0d] = 0x01
  [genesys_gl841] reg[0x0f] = 0x01
  [genesys_gl841] gl841_bulk_write_register: wrote 4 registers
  [genesys_gl841] gl841_begin_scan: completed
  [genesys_gl841] gl841_bulk_read_data: requesting 31200 bytes
  [genesys_gl841] gl841_bulk_read_data: trying to read 31200 bytes of 
 data
  [genesys_gl841] gl841_bulk_read_data read 31200 bytes, 0 remaining
  [genesys_gl841] gl841_bulk_read_data: completed
  [genesys_gl841] gl841_led_calibration: average: 0,801,302
  [genesys_gl841] gl841_led_calibration: 
 avga=367,expr=0,expg=0,expb=0,avge=0
  Exception en point flottant (floating point exception)
 
 that line above should be more like this:
 [genesys_gl841] gl841_led_calibration: average: 43901,43865,43387
 
 But you can ignore led-calibration for now, that is not essential when
 debugging the backend. Just make sure the exposure settings in
 Genesys_Sensor.regs_0x10_0x1d are good, for example from an usb log the
 last register write to 0x10-0x15 before receiving actual scanned data.
 If those stay all zero, the rgb-leds in your scanner are very probably
 not controlled using the rgb-led-control-feature of the gl84x.
 
 You can disable led calibration by commenting out the code in
 genesys_flatbed_calibration. Offset/Gain calibration can be commented
 out when the values in Genesys_Frontend are good, Shading calibration
 can be disabled when you add OPTICAL_FLAG_DISABLE_SHADING to the flags
 for gl841_init_optical_regs_scan. When shading calibration is disabled,
 you get vertical stripes, the others lead to too dark/bright r/g/b 
 channels.
 
 Things that may be missing:
 * leds need to be controlled correctly
 * cis-sensor needs to get the correct clock signals(line toggle+pixel
   clock, half-resolution signal is optional for now)
 * the analog frontend registers need to be setup correctly in
   Genesys_Frontend
 * the readout position in the data stream from the analog frontend may
   need tweaking(registers 0x52,0x53)
 
 When that is done, you should be able to get an image from your
 scanner, although calibration may be lacking.
 
 The data stream inside gl84x based cis-scanners(at least the LiDE
 35/50/60) looks like this:
 -+
 gl84x!
 -+
   ! r,g,b led control line, selects colors r, g, b in turn,
   ! controls exposure for each color
 +-+
 !r,g,b led!
 +-+
   ! r,g,b light
 ++
 !original!
 ++
   ! r,g,b component
 +--+
 !cis sensor!
 +--+
   ! voltages proportional to light intensity
 +---+
 !analog frontend!
 +---+
   ! 16bit intensity, multiplexed on 8bit data bus
 -+
 gl84x!
 -+
 
  See sample image toto.jpg too (when commenting zero division in
  genesys_gl841.c the scanner scans an image).
 
  Help needed thanks
 
  Guillaume
 
 Regards,
   Pierre
-- next part --
A non-text attachment was scrubbed...
Name: toto.jpg
Type: image/jpeg
Size: 30706 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080121/b13a9468/attachment-0001.jpg
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

OK, my motor moves !

But, someting doesn't work during initialisation : I get floating point 
error !

I modified genesys_gl841.c for instrumentation and genesys_devices.c 
(genesys_sensor section) in accordance to my windows usb snoop log (see 
attacement).

SANE_DEBUG_GENESYS_GL841=255 scanimage 
-device-name=genesys:libusb:001:066  toto.pnm ends with :

[genesys_gl841] reg[0x86] = 0x00
[genesys_gl841] reg[0x87] = 0x00
[genesys_gl841] gl841_bulk_write_register: wrote 104 registers
[genesys_gl841] gl841_led_calibration: starting first line reading
[genesys_gl841] gl841_begin_scan
[genesys_gl841] gl841_bulk_write_register (elems = 4)
[genesys_gl841] reg[0x03] = 0x5f
[genesys_gl841] reg[0x01] = 0x81
[genesys_gl841] reg[0x0d] = 0x01
[genesys_gl841] reg[0x0f] = 0x01
[genesys_gl841] gl841_bulk_write_register: wrote 4 registers
[genesys_gl841] gl841_begin_scan: completed
[genesys_gl841] gl841_bulk_read_data: requesting 31200 bytes
[genesys_gl841] gl841_bulk_read_data: trying to read 31200 bytes of data
[genesys_gl841] gl841_bulk_read_data read 31200 bytes, 0 remaining
[genesys_gl841] gl841_bulk_read_data: completed
[genesys_gl841] gl841_led_calibration: average: 0,801,302
[genesys_gl841] gl841_led_calibration: avga=367,expr=0,expg=0,expb=0,avge=0
Exception en point flottant (floating point exception)

See sample image toto.jpg too (when commenting zero division in 
genesys_gl841.c the scanner scans an image).

Help needed thanks

Guillaume


-- next part --
A non-text attachment was scrubbed...
Name: genesys_devices.c
Type: text/x-csrc
Size: 22784 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080115/a47bdceb/attachment-0001.c
 
-- next part --
A non-text attachment was scrubbed...
Name: toto.jpg
Type: image/jpeg
Size: 7625 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080115/a47bdceb/attachment-0001.jpg
 

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Guillaume Gastebois schrieb:
 Hello,

 I tried with : SANE_DEBUG_GENESYS_GL841=255 scanimage
 --device-name=genesys:libusb:001:005  toto.pnm

 Result can be found in attachement.

 It locks on last line and did nothing else.

It sits in gl841_slow_back_home, genesys_gl841.c:3581-3597. You need to
get the head to move and figure out if/how the home position switch is
activated. If the motor or the switch can be deactivated, some GPIO is
typically responsible for that. The motor and home-switch of my LiDE35
need to be enabled using GPIO, and default to off. There is no standard
regarding these settings, so you need to go through your usb logs to
find a working GPIO-setting-sequence.

Hope that helps,
  Pierre

In windows snoop I find this init sequence :

\x01\x82
\x02\x10
\x03\x50
\x04\x10
\x05\x8c
\x06\x18
\x08\x00
\x09\x21
\x0a\x00
\x0d\x00
\x10\x00
\x11\x00
\x12\x00
\x13\x00
\x14\x00
\x15\x00
\x16\x20
\x17\x06
\x18\x00
\x19\xff
\x1a\x24
\x1c\x00
\x1d\x04
\x1e\x10
\x1f\x04
\x20\x02
\x21\x10
\x22\x7f
\x23\x7f
\x24\x10
\x25\x00
\x26\x00

\x27\x00
\x28\x00
\x29\xff
\x2a\x00
\x2b\x00
\x2c\x09
\x2d\x60
\x2e\x80
\x2f\x80
\x30\x00
\x31\x10
\x32\x15
\x33\x0e
\x34\x40
\x35\x00
\x36\x2a
\x37\x30
\x38\x2a
\x39\xf8
\x3c\x02
\x3d\x00
\x3e\x00
\x3f\x00
\x52\x02
\x53\x04
\x54\x02
\x55\x04
\x56\x02
\x57\x04
\x58\x0a
\x59\x71
\x5a\x55

\x5d\x20
\x5e\x41
\x5f\x40
\x60\x00
\x61\x00
\x62\x00
\x63\x00
\x64\x00
\x65\x00
\x66\x00
\x67\x80
\x68\x80
\x69\x20
\x6a\x20
\x6b\x03
\x6c\x02
\x6d\x80
\x6e\x7f
\x6f\xe0
\x70\x00
\x71\x05
\x72\x07
\x73\x09
\x75\x01
\x76\xff
\x78\x00
\x79\x3f
\x7b\x00
\x7c\x1e
\x7d\x11
\x7e\x00
\x7f\x50

\x80\x00
\x81\x00
\x82\x0f
\x83\x00
\x84\x0e
\x85\x00
\x86\x0d
\x87\x00
\x88\x00
\x89\x00

Is that so different as lide 60 ?

Thank you
Guillaume

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Guillaume Gastebois schrieb:
 Hello,

 I tried with : SANE_DEBUG_GENESYS_GL841=255 scanimage
 --device-name=genesys:libusb:001:005  toto.pnm

 Result can be found in attachement.

 It locks on last line and did nothing else.
 It sits in gl841_slow_back_home, genesys_gl841.c:3581-3597. You need to
 get the head to move and figure out if/how the home position switch is
 activated. If the motor or the switch can be deactivated, some GPIO is
 typically responsible for that. The motor and home-switch of my LiDE35
 need to be enabled using GPIO, and default to off. There is no standard
 regarding these settings, so you need to go through your usb logs to
 find a working GPIO-setting-sequence.

 Hope that helps,
  Pierre
 
 In windows snoop I find this init sequence :
 


 \x01\x82  \x80
 \x02\x10  \x38
 \x03\x50  \x40
 \x04\x10  \x10
 \x05\x8c  \x40
 \x06\x18  \x18
  \x07  \x00
 \x08\x00  \x00
 \x09\x21  \x10
 \x0a\x00  \x00
 \x0d\x00  \x01
 \x10\x00  \x07
 \x11\x00  \xff
 \x12\x00  \x0e
 \x13\x00  \x89
 \x14\x00  \x0c
 \x15\x00  \xa5
 \x16\x20  \x00
 \x17\x06  \x01
 \x18\x00  \x00
 \x19\xff  \x50
 \x1a\x24  \x00
 \x1c\x00  \x00
 \x1d\x04  \x01
 \x1e\x10  \x10
 \x1f\x04  \x01
 \x20\x02  \x20
 \x21\x10  \x05
 \x22\x7f  \x20
 \x23\x7f  \x20
 \x24\x10  \x05
 \x25\x00  \x00
 \x26\x00  \x04

 \x27\x00  \x08
 \x28\x00  
 \x29\xff  \xff
 \x2a\x00
 \x2b\x00
 \x2c\x09  \x04
 \x2d\x60  \xb0
 \x2e\x80  \x80
 \x2f\x80  \x80
 \x30\x00  \x00
 \x31\x10  \x7f
 \x32\x15  \x28
 \x33\x0e  \x8a
 \x34\x40  \x7e
 \x35\x00  \x00
 \x36\x2a  \x3b
 \x37\x30  \xc6
 \x38\x2a  \x4f
 \x39\xf8  \xc1
 \x3c\x02 
 \x3d\x00  \x00
 \x3e\x00  \x00
 \x3f\x00  \x01
 \x52\x02  \x03
 \x53\x04  \x05
 \x54\x02  \x02
 \x55\x04  \x05
 \x56\x02  \x02
 \x57\x04  \x05
 \x58\x0a  \x03
 \x59\x71  \x03
 \x5a\x55  \x40

 \x5d\x20
 \x5e\x41  \x02
 \x5f\x40  \x05
 \x60\x00  \x00
 \x61\x00  \x00
 \x62\x00  \x00
 \x63\x00  \x00
 \x64\x00  \x00
 \x65\x00  \x00
 \x66\x00  \xff
 \x67\x80  \x7f
 \x68\x80  \x7f
 \x69\x20  \x05
 \x6a\x20  \x05
   \x6b\x03  \x03
   \x6c\x02  \x82
   \x6d\x80  \x80
   \x6e\x7f  \xef
   \x6f\xe0  \x80
 \x70\x00  \x00
 \x71\x05  \x00
 \x72\x07  \x00
 \x73\x09  \x00
 \x75\x01  \x00
 \x76\xff  \x00
 \x78\x00  \x00
 \x79\x3f  \x00
 \x7b\x00  \x00
 \x7c\x1e  \x00
 \x7d\x11  \x00
 \x7e\x00  \x00
 \x7f\x50  \x00
 
 \x80\x00  \x00
 \x81\x00  \x00
 \x82\x0f  \x00
 \x83\x00  \x00
 \x84\x0e  \x00
 \x85\x00  \x00
 \x86\x0d  \x00
 \x87\x00  \x00
 \x88\x00
 \x89\x00
 
 Is that so different as lide 60 ?

I put a similar result from my scanner next to your result. For the
GPIOs, at least the direction bits are different, so i guess they are
used differently. You may want to write a small test-program for your
scanner, similar to what i did for mine[1], using your usb log. If you
got that to work, you can play around with the gpio pins to figure out
their function. Alternatively, you can take a lot of usb logs and guess
the meaning of the pins.

My scanner(Canon LiDE 35) has these functions, as far as i found out:

pinfunction  direction
GPIO1: SCAN button   in
GPIO2: FILE button   in
GPIO3: E-MAIL button in
GPIO4: COPY button   in
GPIO8: overall power?out
GPIO9: save powerout
GPIO16: Full resolution  out
GPO17: lamp+home sensor? out
GPO18: extra power?  out

You may find some of these. Especially the Full/Half resolution
function should be somewhere.

Regards,
  Pierre

[1] http://pirsoft-dsl-dropzone.de/canon-lide35.tbz2

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I tried with : SANE_DEBUG_GENESYS_GL841=255 scanimage 
--device-name=genesys:libusb:001:005  toto.pnm

Result can be found in attachement.

It locks on last line and did nothing else.

Thank you for help because I'm blocked.

Guillaume
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: debug_gl841.txt
Url: 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080108/0bd97021/attachment-0001.txt
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I tried with : SANE_DEBUG_GENESYS_GL841=255 scanimage
 --device-name=genesys:libusb:001:005  toto.pnm
 
 Result can be found in attachement.
 
 It locks on last line and did nothing else.

It sits in gl841_slow_back_home, genesys_gl841.c:3581-3597. You need to
get the head to move and figure out if/how the home position switch is
activated. If the motor or the switch can be deactivated, some GPIO is
typically responsible for that. The motor and home-switch of my LiDE35
need to be enabled using GPIO, and default to off. There is no standard
regarding these settings, so you need to go through your usb logs to
find a working GPIO-setting-sequence.

Hope that helps,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

I can't make led on and motor move with my LiDE 90.

I modify CVS with replacing all LiDE 60 0x221c with 0x199 pid of 
LiDE 90.

scanimage -L returns my LiDE 90, but SANE_DEBUG_GENESYS=255 scanimage 
--device-name=genesys:libusb:001:005  toto.pnm

gives me a log looping indefinitelly on : [genesys] 
sanei_genesys_read_register (0x41, 0xf4) completed

see my attached file.

Is any genesys specialist to explain me what I did wrong !!! (my scanner 
is working on windows in my office)

Thank you

Guillaume
-- next part --
A non-text attachment was scrubbed...
Name: scanimage.log
Type: text/x-log
Size: 17557 bytes
Desc: not available
Url : 
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080107/7102c450/attachment-0001.bin
 

[sane-devel] Canon LiDE 90

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
 Hello,
 
 I can't make led on and motor move with my LiDE 90.
 
 I modify CVS with replacing all LiDE 60 0x221c with 0x199 pid of
 LiDE 90.
 
 scanimage -L returns my LiDE 90, but SANE_DEBUG_GENESYS=255 scanimage
 --device-name=genesys:libusb:001:005  toto.pnm
 
 gives me a log looping indefinitelly on : [genesys]
 sanei_genesys_read_register (0x41, 0xf4) completed
 
 see my attached file.
 
 Is any genesys specialist to explain me what I did wrong !!! (my scanner
 is working on windows in my office)

You should try to use SANE_DEBUG_GENESYS_GL841=255, too. This will give
you more or less a full trace of the calls happening in the backend.

I _think_ the backend tries to do a head move, but the scanner is
immediately ready again. No idea, why this happens.

Regards,
  Pierre

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Thank you Ralf,

But LiDE 60 PID only appears 2 times in genesys_devices.c and 1 time in
genesys.conf.in I still change them and no result (scanimage -L return LiDE 90
but can't move or turn on led with scanimage toto.pnm!!)

For help I did a usbsnoop and with a usbsnoop2libusb.pl a .c file. Maybe it can
help you (or others). You can find then to :
http://ggastebois.free.fr/lide90_snoop

Regards

Guillaume

[sane-devel] Canon LiDE 90

[Ralf Haueisen]

Hi Guillaume.

Maybe your forgot to change  /etc/sane.d/genesys.conf:

# genesys.conf: Configuration file for Genesys Logic GL646 and GL841 based 
scanners

#
# scanners that are not yet supported
# uncomment them only for developpment purpose
#

# UMAX Astra 4500 and Avision iVina 1600
#usb 0x0638 0x0a10

# Hewlett Packard ScanJet 2400c
#usb 0x03f0 0x0a01

# Hewlett Packard ScanJet 3670c
#usb 0x03f0 0x1405

# Plustek OpticPro ST24
#usb 0x07b3 0x0601

#
# supported scanners
#

# Medion MD5345/MD6228/MD6471
usb 0x0461 0x0377

# Hewlett Packard ScanJet 2300c
usb 0x03f0 0x0901

# Canon LiDE 35/40/50
usb 0x04a9 0x2213

# Canon LiDE 60
usb 0x04a9 0x1900

 -Urspr?ngliche Nachricht-
 Von: Guillaume Gastebois guillaume.gastebois at free.fr
 Gesendet: 31.12.07 01:49:51
 An: sane-devel at lists.alioth.debian.org
 Betreff: [sane-devel]  Canon LiDE 90


 
 Hello,
 
 I'm sorry to disturb you, but I can't do someting with my LiDE 90. You 
 seems to be more advanced than me. (I'm under Mandriva 2008)
 
 Thats what I do :
 
 cvs -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane login
 
 cvs -z3 -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane co 
 sane-backends
 
 cvs -z3 -d:pserver:anonymous at cvs.alioth.debian.org:/cvsroot/sane co 
 experimental
 
 copy genesys files from experimental to backend
 
 ./configure --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc 
 --libdir=/usr/lib --sbindir=/usr/sbin --enable-scsibuffersize=32768 
 --mandir=/usr/share/man
 
 edit genesys_devices.c and add a copy of lide_60 and change all lide_60 
 to lide_90 and at the end adding lide_90 section. (see attached 
 genesys_devices.c)
 
 make
 
 make install (as root)
 
 scanimage -L = device `genesys:libusb:001:005' is a Canon LiDE 90 
 flatbed scanner
 
 but with scanimage  toto.pnm or xsane nothing appends 
 
 What is wrong ??
 
 Thank you in advance for help.
 
 Guillaume
 
 
 hr
 -- 
 sane-devel mailing list: sane-devel at lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/sane-devel
 Unsubscribe: Send mail with subject unsubscribe your_password
  to sane-devel-request at lists.alioth.debian.org
 


_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071distributionid=0066

[sane-devel] Canon LiDE 90

[Guillaume Gastebois]

Hello,

Thank you for answer, but I had modified my genesys.conf :

# Canon LiDE 35/40/50
usb 0x04a9 0x2213

# Canon LiDE 60
usb 0x04a9 0x221c

# Canon LiDE 90
usb 0x04a9 0x1900

No other idea, because with scanimage nothong happends (no light, no 
moves...)

Guillaume