from:"Pierre Willenbrock"

Hi Guillaume,

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

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

Sorry for the delay.

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

[sane-devel] Canon LiDE 90

Volker Grabsch 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

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

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

2008-03-11 Thread Pierre Willenbrock

Hi,

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

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

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

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

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

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

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

Will merge that.

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

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

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

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

That is not unexpected.

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

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

 Regards
 Guillaume

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-03-09 Thread Pierre Willenbrock

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

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

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

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

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

Regards,
  Pierre

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

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

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

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

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

 Regards,
   Pierre

 regards
 Guillaume

 Pierre Willenbrock a ?crit :
 Hi,

 Guillaume Gastebois schrieb:
 Hello,

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

 Candidates:

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

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

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

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

 Another thing : I always have a brither vertical line where there is a
 small black rectangle in the calibration area.
 The small black rectangle is included when acquiring the white level.
 Reduce shading_lines(second to last entry) in Genesys_Model to 250, that
 way it is not seen anymore.

 Done, works.

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

 Done.


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

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

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

 No guarantee that this helps at all.

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

 Regards,
   Pierre

[sane-devel] Canon LiDE 90

2008-03-01 Thread Pierre Willenbrock

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

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

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

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

I hope you had a nice week holidays.

Regards,
  Pierre

 regards
 Guillaume
 
 Pierre Willenbrock a ?crit :
 Hi,

 Guillaume Gastebois schrieb:
 Hello,

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

 Candidates:

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

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

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

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

 Another thing : I always have a brither vertical line where there is a
 small black rectangle in the calibration area.
 The small black rectangle is included when acquiring the white level.
 Reduce shading_lines(second to last entry) in Genesys_Model to 250, that
 way it is not seen anymore.

 Done, works.

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

 Done.


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

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

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

 No guarantee that this helps at all.

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

 Regards,
   Pierre

[sane-devel] Canon LiDE 90

2008-02-23 Thread Pierre Willenbrock

Hi,

Guillaume Gastebois schrieb:
 Hello,
 
 So, we need to check what parts of the clocking we need to setup
 differently.

 Candidates:

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

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

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

Add them to gl841_init_registers.

 Another thing : I always have a brither vertical line where there is a
 small black rectangle in the calibration area.
 The small black rectangle is included when acquiring the white level.
 Reduce shading_lines(second to last entry) in Genesys_Model to 250, that
 way it is not seen anymore.

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

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

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

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

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

No guarantee that this helps at all.

 Regards
 Guillaume

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

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-22 Thread Pierre Willenbrock

Hi,

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

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

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

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

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

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

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

Candidates:

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

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

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

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

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

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

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

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

 Regards
 Guillaume


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

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

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

Regards,
  Pierre

 Pierre Willenbrock a ?crit :
 Pierre Willenbrock schrieb:
 Hi,

 Guillaume Gastebois schrieb:
 Hello,

 So, what's the next step ? Re-enabling shading ?
 Yes, but only after the shading-calibration is able to get black level
 information.(This really needs a better api..)

 I commited a prerequisite for shading calibration to work for your
 scanner. When enabling shading, update from cvs and then use
 GENESYS_FLAG_DARK_CALIBRATION instead of
 GENESYS_FLAG_DARK_WHITE_CALIBRATION.

 Regards,
   Pierre

 Do you think that last modification for (i = 150; i... is necessary ?
 Yes. Some time back, that part of the code just used the middle half of
 the scan, exactly to drop the dummy black pixels at the begin. That
 didn't work too well, missing some low black levels.

 Is it time to fine tune registers 52... ?
 Try

[sane-devel] Canon LiDE 90

2008-02-21 Thread Pierre Willenbrock

Pierre Willenbrock schrieb:
 Hi,
 
 Guillaume Gastebois schrieb:
 Hello,

 So, what's the next step ? Re-enabling shading ?
 
 Yes, but only after the shading-calibration is able to get black level
 information.(This really needs a better api..)

I commited a prerequisite for shading calibration to work for your
scanner. When enabling shading, update from cvs and then use
GENESYS_FLAG_DARK_CALIBRATION instead of
GENESYS_FLAG_DARK_WHITE_CALIBRATION.

Regards,
  Pierre

 Do you think that last modification for (i = 150; i... is necessary ?
 
 Yes. Some time back, that part of the code just used the middle half of
 the scan, exactly to drop the dummy black pixels at the begin. That
 didn't work too well, missing some low black levels.
 
 Is it time to fine tune registers 52... ?
 
 Try increasing register 53, 55, 57 by one. Attached is a small program,
 that shows the probability of any two-byte pair appearing in a file. It
 takes the file as input and dumps an portable anymap(pnm) as output.
 I created that program for something completely unrelated, but it proved
 useful.
 
 I used it on offset1_1.pnm(as offset1_0.pnm is only black).
 The image should show a fuzzy vertical and horizontal bar, near
 top/left. Currently, the horizontal bar is more a line, the vertical bar
 is correct(it shows the relationship between the low byte of one pixel
 and the high byte of the _next_ pixel).
 
 Regards
 Guillaume
 
 Regards,
   Pierre
 
 Pierre Willenbrock a ?crit :
 Guillaume Gastebois schrieb:
 Hello,

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

 Hi,

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

 I hope this fixes that part of the calibration.

 Regards,
   Pierre

 Regards
 Guillaume

[sane-devel] Canon LiDE 90

2008-02-21 Thread Pierre Willenbrock

Guillaume Gastebois schrieb:
Hello,

Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

Hi,

Guillaume Gastebois schrieb:
Hello,

So, what's the next step ? Re-enabling shading ?
Yes, but only after the shading-calibration is able to get black level
information.(This really needs a better api..)

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

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

Do you think that last modification for (i = 150; i... is necessary ?
Yes. Some time back, that part of the code just used the middle half of
the scan, exactly to drop the dummy black pixels at the begin. That
didn't work too well, missing some low black levels.

Is it time to fine tune registers 52... ?
Try increasing register 53, 55, 57 by one. Attached is a small program,
that shows the probability of any two-byte pair appearing in a file. It
takes the file as input and dumps an portable anymap(pnm) as output.
I created that program for something completely unrelated, but it proved
useful.

I used it on offset1_1.pnm(as offset1_0.pnm is only black).
The image should show a fuzzy vertical and horizontal bar, near
top/left. Currently, the horizontal bar is more a line, the vertical bar
is correct(it shows the relationship between the low byte of one pixel
and the high byte of the _next_ pixel).

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

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

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

Regards
Guillaume

Regards
Guillaume
Regards,
Pierre

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

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

Hi,

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

I hope this fixes that part of the calibration.

Regards,
Pierre

Regards
Guillaume

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

[sane-devel] Canon LiDE 90

2008-02-20 Thread Pierre Willenbrock

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

Hi,

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

I hope this fixes that part of the calibration.

Regards,
  Pierre

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

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

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

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

 Regards,
   Pierre

 Regards
 Guillaume

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

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

 Regards,
   Pierre

 Regards
 Guillaume

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

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

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

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

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


 Regards,
   Pierre

[sane-devel] Canon LiDE 90

2008-02-19 Thread Pierre Willenbrock

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

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

Regards,
  Pierre

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

 I made two tests today :

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

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

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

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


 Regards,
   Pierre

[sane-devel] Canon LiDE 90

2008-02-19 Thread Pierre Willenbrock

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

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

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

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

Regards,
  Pierre

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

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

 Regards,
   Pierre

 Regards
 Guillaume

 Selon Pierre Willenbrock pierre at pirsoft.dnsalias.org:

 Guillaume Gastebois schrieb:
 Hello,

 I made two tests today :

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

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

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

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


 Regards,
   Pierre

[sane-devel] Canon LiDE 90

2008-02-18 Thread Pierre Willenbrock

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

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

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

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

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

Regards,
  Pierre

[sane-devel] About the GL646(_HP) and future release of SANE

2008-02-17 Thread Pierre Willenbrock

Vidar S?terb? schrieb:
 Hi,
 
 FYI, I was googling for information on the GL646 (I have a HP Scanjet
 2400) when I came across this datasheet:
 http://www.ic-on-line.cn/IOL_gl646/PdfView/833184.htm
 

Another source for that datasheet is probably
http://www.genesyslogic.com/_en/product_01_1.php?id=44

 Cheers,
 Vidar

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-17 Thread Pierre Willenbrock

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

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

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

 Regards
 Guillaume

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-15 Thread Pierre Willenbrock

Pierre Willenbrock schrieb:
 Guillaume Gastebois schrieb:
 Hello,

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

 What seems strange in calibration ?

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

Hi,

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

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

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

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-14 Thread Pierre Willenbrock

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

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

Regards,
  Pierre

[sane-devel] Canon LiDE 90

Pierre Willenbrock 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] genesys_gl841.c: infinite loops

Pierre Willenbrock schrieb:
 Stefan Lucke schrieb:
 Hi,
 I guess there are 3 possibilities for infinite loops.
 Attached patch fixes this and adjusts loop threshold
 to given comments..

 
 Thanks for spotting these.
 
 We have never had a problem with those loops, but it is certainly a good
 idea to have the code working as the comments in the code suggest. A
 short test revealed no breakages.
 
 I will commit these corrections after the release.

commited.

 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 80 (2nd try)

Stefan Lucke schrieb:
On Monday 11 February 2008, Pierre Willenbrock wrote:
Reinhard Biegel schrieb:
Am Monday, 11. February 2008 schrieb Stefan Lucke:

At that moment, I guess you'll see messages like:
new high speed USB device using ehci_hcd and address nn
via dmesg.
Hi,
Yes, thats right.

Changing the write to reg 0x6b from 0x0c to 0x08 fixes that.
Scanner is producing noisy image now.

Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect
two
pins which are marked as 'reserved' in the datasheet? They are only
documented for GL843.
Register 0x6b is very different between GL841/2 and GL843. But the
documentation around the pins controlled with 0x6b is a bit lacking.

So we need to write reserved I/O bits, (0x6b) need to write to undefined
gamma addresses (0x5b/5c - 0x0c00). Thats really magic. Both areas
are defined for GL843 but not for GL841/2.

I just tested that on my scanner. Gamma data written to 0xc000 ended up
in Gamma RAM, 0x. Can someone please play around with the actual
data transmitted and the address? It may be a dummy write. On the other
hand, the firmware may intercept that write(for whatever reasons it
could not use another usb vendor transfer).

If you want to test that yourself, i attached my program. You will
probably need to fiddle with the initialisation code.

Regards,
Pierre
-- next part --
A non-text attachment was scrubbed...
Name: gl842-memory.tbz2
Type: application/octet-stream
Size: 7331 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080213/4ae75f51/attachment.obj

[sane-devel] Canon LiDE 80 (2nd try)

2008-02-12 Thread Pierre Willenbrock

Gerhard Jaeger schrieb:
 On Tuesday 12 February 2008 03:41:49 Reinhard Biegel wrote:
 On Monday, 11. February 2008, Pierre Willenbrock wrote:
 Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to
 3.0.5, as someone said, and GL842 begins with 3.0.6
 
 that was me. But it's not quite clear. got also some info that
 GK842 starts @ 303
 
 bcdDevice of mine is 0302.
 
 So probably it's a GL841. Any chance to disassemble the device?
 
No need to. i just meant to make sure that it is not a version on the
edge to GL843(if there is such an edge). My Canon LiDE 35 has 0305, and
is said to contain a GL842, according to [1], but the LiDE 50 there is
0303 and GL841. Apart from that the two datasheets show suspiciously few
differences.

Regards,
  Pierre

[1] http://www.sane-project.org/unsupported/canon-lide-50.html

[sane-devel] Canon LiDE 90

2008-02-12 Thread Pierre Willenbrock

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

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

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

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-12 Thread Pierre Willenbrock

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

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

Regards,
  Pierre

[sane-devel] General technical docs for flatbed scanners

2008-02-11 Thread Pierre Willenbrock

Hi list,

anybody knows if/where to find $subject on the web? Something that
describes some details of motor control, lamp control and analog/digital
postprocessing, as well as the general scanning operating. Just enough
for a developer of a driver for a dumb chip(like the genesys chips).

If noone comes up with anything, i will try to create such a thing and
post it here for comments.

Regards,
  Pierre

[sane-devel] Canon LiDE 80 (2nd try)

2008-02-11 Thread Pierre Willenbrock

Reinhard Biegel schrieb:
 Am Monday, 11. February 2008 schrieb Stefan Lucke:
 ...
 [genesys_gl841] reg[0x6b] = 0x02
 [genesys_gl841] reg[0x6e] = 0x6d
 [genesys_gl841] gl841_bulk_write_register: failed while writing command:
 Invalid argument
 scanimage: open of device genesys:libusb:001:010 failed: Invalid argument
 At that moment, I guess you'll see messages like:
  new high speed USB device using ehci_hcd and address nn
 via dmesg.
 
 Hi,
 Yes, thats right.
 
 Changing the write to reg 0x6b from 0x0c to 0x08 fixes that. 
 Scanner is producing noisy image now.
 
 Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect two 
 pins which are marked as 'reserved' in the datasheet? They are only 
 documented for GL843.

Register 0x6b is very different between GL841/2 and GL843. But the
documentation around the pins controlled with 0x6b is a bit lacking.

Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to
3.0.5, as someone said, and GL842 begins with 3.0.6

 After scanning I have to replug the scanner, otherwise I get an error message 
 telling me the document feeder is jammed. Curiously, if I set 
 SANE_DEBUG_GENESYS, there comes up another error about a failed bulk_write.

The feeder jammed error happens when the backend thinks your scanning
head is stuck. For example when someone forgot to open the lock. I guess
we need SANE2 for more/better error messages. It is probably not really
stuck, but the sensor input is incorrect.

 
 Also I noticed that the LED isn't continuously illuminated. In one half it's 
 continuous, but in the other there are small gaps (about 1mm) with about 4mm 
 spacing between. In the middle there are a few with bigger spacing.

Sounds like it would normally be backtracking between the lighted areas,
but does not for some reason. Just guessing. The LiDE 80 support is far
from complete.

 
 Which way is your scanner connected ?
 Directly to the computer, no hubs.
 
 Regards,
 Reinhard
 

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-09 Thread Pierre Willenbrock

Hi Guillaume,

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

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

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

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

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

home position
+
!   black area
+
!   white area
+

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

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

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

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

 Another thing : when scaning in color the leds are blue 

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

Regards,
  Pierre

[sane-devel] Canon LiDE 90

2008-02-07 Thread Pierre Willenbrock

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

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

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

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

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

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

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

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

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

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

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

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

 
 Only in calibration function ?

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

Regards,
  Pierre

 
 Regards
 Guillaume
 
 Regards,
   Pierre

[sane-devel] Canon LiDE 90

Guillaume Gastebois 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] genesys_gl841.c: infinite loops

Stefan Lucke schrieb:
 Hi,
 I guess there are 3 possibilities for infinite loops.
 Attached patch fixes this and adjusts loop threshold
 to given comments..
 

Thanks for spotting these.

We have never had a problem with those loops, but it is certainly a good
idea to have the code working as the comments in the code suggest. A
short test revealed no breakages.

I will commit these corrections after the release.

Regards,
  Pierre

[sane-devel] Canon LiDE 80 (2nd try)

Hi Stefan,

(more text inline)

Stefan Lucke schrieb:
 On Tuesday 05 February 2008, Stefan Lucke wrote:
 Hi,

 I've seen there is some progress on lide 90 and I want to step in and
 like to ask if there could be done something for my LiDE 80 too.
 I cloned the canon_lide_60_model entry

 -- scanimage with debug messages : --
 [sanei_debug] Setting debug level of genesys to 255.
 [genesys] SANE Genesys backend version 1.0 build 9 from sane-backends 
 1.0.18-cvs
 [genesys] sane_init: authorize != null
 [genesys] sane_init: little endian machine
 [genesys] sane_init: reading config file `genesys.conf'
 [genesys] sane_init: config file line 1: trying to attach `usb 0x04a9 0x2214'
 ..
 [genesys_gl841] gl841_bulk_write_register (elems = 104)
 [genesys_gl841] reg[0x01] = 0xa0
 [genesys_gl841] reg[0x02] = 0x38
 [genesys_gl841] reg[0x03] = 0x5f
 [genesys_gl841] reg[0x04] = 0x10
 [genesys_gl841] reg[0x05] = 0x40
 [genesys_gl841] reg[0x06] = 0x18

 -- I modified this, debug message is written before ..bulk_write..() . --

 [genesys_gl841] gl841_bulk_write_register: failed while writing command: 
 Invalid argument
 scanimage: open of device genesys:libusb:001:017 failed: Invalid argument
 [genesys] sane_exit: start
 [genesys] sane_exit: exit
 
 Some further info:
 I placed some win98 logfiles at http://lucke.in-berlin.de/lide-80/ .
 
 During my search in the list history, I found a test program in this mail:
 http://lists.alioth.debian.org/pipermail/sane-devel/2006-October/017930.html

I must admit, i totally forgot about that.. lectures where starting at
that time at my university.

 
 Using the following stripped down version of usbsnoop-300dpi_color.c,
 helped to get rid of the sudden disconnect from below.
 -- snip --
 set_write_register(0x6b, 0x0c);
 set_write_register(0x06, 0x10);

first, try if either of the following is enough to get past writing
register 0x06:
set_write_register(0x6b, 0x08);
set_write_register(0x6b, 0x04);

put that write to 0x6b into gl841_init, before the /* Write initial
registers */, and make sure the other places where 0x6b is written
preserve the needed bits. That may get scanimage to o further with a
freshly plugged in scanner.

Regards,
  Pierre

 -- snip --
 
 Both lines are required!
 (Note: disconnect has timestamp earlier than USBDEVFS message).
 
 Even with turned off LED and some motor sound (movement in the wrong
 direction ??), scanimage produced some pnm files.
 
 To be continued, but I really need some help, as I've no idea 
 about scanner hardware.
 
 -- dmesg output (kernel 2.6.23.13): --
 [ 5298.424302] usb 1-7: new high speed USB device using ehci_hcd and address 
 17
 [ 5298.480244] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0)
 [ 5298.491202] usb 1-7: configuration #1 chosen from 1 choice
 [ 5312.035169] usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64 
 rq 4 len 2 ret -71
 [ 5312.035148] usb 1-7: USB disconnect, address 17
 [ 5312.188163] usb 1-7: new high speed USB device using ehci_hcd and address 
 18
 [ 5312.244105] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0)
 [ 5312.255079] usb 1-7: configuration #1 chosen from 1 choice

[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 80 (2nd try)