Re: [sane-devel] Canon Lide 90 support
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
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
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
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
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
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
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
An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080412/037335de/attachment.htm
[sane-devel] Canon LiDE 90
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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 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
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
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
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
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 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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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