[sane-devel] Re : Re: GL842
Hello, On Thu, Jul 03, 2008 at 02:52:22PM -0700, Donald Endres wrote: I got the attachment from http://lists.alioth.debian.org/pipermail/sane-devel/2008-March/021440.html ( is that the newest version ? ) and I will try to reproduce your work. Same for me. :-) A general question: Where is the code for canon-lide-90? Is it already completely in the CVS? Despite some problems, the code developed by Guillaume and Pierre is the best we current have. It would be a pity if that code got lost in the mailing list archive. I think it is not in CVS yet. I'll try to send new patch (to be added in CVS ?) despite no huge progress since month. (just fix first scan power up problem) More general: When are such contributions usually added to the CVS? Good question. Greets, Volker -- Volker Grabsch ---(())--- Administrator NotJustHosting GbR Regards Guillaume
[sane-devel] GL842
Hello, looks like: http://lists.alioth.debian.org/pipermail/sane-devel/2007-November/020199.html was the last attempt to get: http://www.sane-project.org/unsupported/canon-lide-90.html to work. I have a disposable one to play with... Can anyone suggest a plan of attack for creating a backend for this? Thanks! - Don No, I try since month to get LiDE 90 to work. I posted a patch for genesys backend few weeks ago. It makes this scanner working under sane but there are calibration and clocking problems. I'll be happy if you can test and modifing it. Regards Guillaume
[sane-devel] Re : Re: LiDE 90 half ccd
Hello, Sorry not to answer quickly I have had lots of work. Nothing very new since months I just do some windows snoops in 1200dpi and 2400dpi translated into C with usbsnoop2libusb.pl. they are : http://ggastebois.free.fr/lide90_snoop/lide90_1200dpi_216x7.c and http://ggastebois.free.fr/lide90_snoop/lide90_2400dpi_216x7.c I don't see big differences Guillaume Gastebois schrieb: Hello, No progress on 2400dpi. DPIHW is 2400 and dpiset 600 for a 300dpi scan. Don't know where to look yet for that problem ! I'd try to get a log from a 2400dpi scan from windows and compare. about byte nibbles modifying reg_0x79 from 0x3f to 0x3e (very few contrasted image) or 0x40(black image) gives me bad images !!! What is effect of this register on clk3 ?? It's very sensible. register 0x77 to 0x79 describe a bitmask, that determines when the clk3 signal is high or low. For 0x0003f(lsb is register 0x79), this would give: time=== ! next pixel bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 ___ ___ |___| | 0x40 is this: bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 _ _ ___| |_| | As you can see, this gives a very short pulse, which will probably not be recognized by the ccd, while 0x3e just shortens the clock pulse at the beginning. The datasheet mentions that the scanner does not need to use the full 18 bits of the bitmask, but uses the first 6, 12 or 18 bits depending on the scanning mode. 12 seems to be correct for the mode the backend programs for cis scanners. Please try if modifying bitmask for clk4(0x7a to 0x7c iirc) shows any effects. Also, other values you may want to try on clk3: 0xff03f, 0xff801f, 0xffc00f. Another thing to try may be to send two clock pulses, for example 0x001c7. If clk3 is connected to the ccd, this may give interesting results(like, reducing the resolution by half), but for the 4-bit latch/D-FlipFlop, only the last clock pulse before the gl841 samples the data bits is relevant. I tryed lot's of differents values for clk3 (differents pulse width and positions) succesless. Only entropy program on offset files gives me sometimes malformed crosses. regards, Guillaume Regards, Pierre Regards Guillaume
[sane-devel] Re : CanoScan LiDE90 support
Hello, I work on, but don't know when It'll be good working. I want to ask if anyone can tell me if there is any hope to have support in sane for this model of scanner. Thanks in advance.
[sane-devel] LiDE 90 half ccd
Hello, OK, if i understand test values you proposed gives : 0xf f0 3f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 ___ |__|| 0xff 80 1f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 _ ___ |___| |__ 0xff c0 0f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 ___ ___ |___| | 0x0 01 c7 bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1... _ _ _ __ |_| |_| |_| I'll give them a try. Do you think 0x7D is needing tuning ? (what are CCD CP and CCD RS ?) Regards Guillaume
[sane-devel] LiDE 90 half ccd
Hello, OK, if i understand test values you proposed gives : 0xf f0 3f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 ___ |__|| see entropy result on : http://ggastebois.free.fr/lide90_snoop/3f03f.pnm 0xff 80 1f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 _ ___ |___| |__ same as before 0xff c0 0f bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 ___ ___ |___| | same as before 0x0 01 c7 bit of 0x79! 0x78 !0x77! 0x79 0 1 2 3 4 5 6 7!0 1 2 3 4 5 6 7!0 1!0 1 2 3 4 5 6... 1 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1... _ _ _ __ |_| |_| |_| gray image with horizontal black lines I'll give them a try. Do you think 0x7D is needing tuning ? (what are CCD CP and CCD RS ?) Regards Guillaume I'll now try with clk1 and clk4. Regards Guillaume
[sane-devel] LiDE 90 half ccd
Hello, No progress on 2400dpi. DPIHW is 2400 and dpiset 600 for a 300dpi scan. Don't know where to look yet for that problem ! about byte nibbles modifying reg_0x79 from 0x3f to 0x3e (very few contrasted image) or 0x40(black image) gives me bad images !!! What is effect of this register on clk3 ?? It's very sensible. Ideas ? regards, Guillaume
[sane-devel] (no subject)
Hello,
Is there a possibility to determine a maximum of parameter like :
typedef struct
{
int optical_res; (OK, for me 2400)
int black_pixels;(don't know how to determine)
int dummy_pixel; (content of 0x34 ?)
int CCD_start_xoffset; (test of page upper border ?)
int sensor_pixels; (just 216/2.54*2400 ?)
int fau_gain_white_ref; (don't know how to determine)
int gain_white_ref; (don't know how to determine)
u_int8_t regs_0x08_0x0b[4]; (OK windows snoop)
u_int8_t regs_0x10_0x1d[14]; (OK windows snoop)
u_int8_t regs_0x52_0x5e[13]; (OK windows snoop)
float red_gamma; (don't know how to determine)
float green_gamma; (don't know how to determine)
float blue_gamma;(don't know how to determine)
u_int16_t *red_gamma_table; (OK NULL)
u_int16_t *green_gamma_table;(OK NULL)
u_int16_t *blue_gamma_table; (OK NULL)
} Genesys_Sensor;
or :
typedef struct
{
SANE_Int base_ydpi;(4800 ? : Lide90 is 2400x4800)
SANE_Int optical_ydpi; (4800 ? : Lide90 is 2400x4800)
SANE_Int max_step_type;(don't know how to determine)
SANE_Int power_mode_count; (don't know how to determine)
Genesys_Motor_Slope slopes[2][3]; (don't know how to determine)
} Genesys_Motor;
Guillaume Gastebois schrieb:
Hello,
I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to
port
that. I backend ready for 2400dpi (I think so regarding portion of code) ?
I am not sure, as there could not happen any testing. But in theory, it
should work. In the future, there should be some afford made to make
other resolutions than 2400, 1200 and 600 work, but these 3 are trivial
with this chip.
I write 2400 dpi in genesys_sensor for lide 90. But how to know pixel number
for
CCD sensor ?
I guess the manufacturer is not lying about the density of the ccd, so
that should be enough. The rest of the settings is in real units. The
backend calculates the exact number of pixel from the density and the
width of the scanning area.
After writing 2400 dpi in sensor, I get quarter sized images !!! Why ?
With 600 dpi in sensor I get full sized images with (300dpi scanning) or
without
half_ccd (1200dpi scanning) (with my code for gpio 14).
Regards
Guillaume
I'd first try to get the correct gpio setting for a full resolution
scan(i.E. at 2400dpi). If you cannot get a full-width-scan, look for the
DPISET register, and try half/twice the dpi there. Also, make sure the
DPIHW is set for the 2400dpi mode.
When that works, figure out how to setup gpios for half_ccd mode. From
the view of the current code base, you are done here. You can try to
find a quarter_ccd mode(which would show up as half-width in the
half_ccd modes), and leave a comment in the code, or even implement the
quarter_ccd mode for real.
Yes, DPIHW is 0x80 (2400dpi)
for 300dpi scanning dpiset is 0x258 (600). Is that good ?
I find that GPIO14 is quarter CCD but by testing all other unknown GPIOs I can't
find one for half CCD Strange no ?
Regards,
Pierre
I see too that If I is image and B is black, I get for 1200dpi, 600dpi, 300dpi
and 150dpi scanning :
1200 :
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
BIII
600 :
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
BBIIIBBB
300 :
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
BBBIIIBB
150 :
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
IIIB
Why ?
Regards
Guillaume
[sane-devel] Question about Genesys_Frontend
Hello,
In genesys backend, we can find :
typedef struct
{
u_int8_t reg[4];
u_int8_t sign[3];
u_int8_t offset[3];
u_int8_t gain[3];
u_int8_t reg2[3];
} Genesys_Frontend;
but in WM8199 regs don't have the same name.
For me registers addresses are :
reg[0]=0x01,reg[1]=0x02,reg[2]=0x03,reg[3]=0x06,
sign[0]=?,sign[1]=?,sign[2]=?,
offset[0]=0x20,offset[1]=0x21,offset[2]=0x22,
gain[0]=0x28,gain[1]=0x29,gain[2]=0x2a,
reg2[0]=0x08,reg2[1]=0x09,reg2[2]=?,
I anybody able to replace ? and/or correct mistakes in text before ?
Thanks
Regards
Guillaume
[sane-devel] LiDE 90 half ccd
Hello, I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to port that. I backend ready for 2400dpi (I think so regarding portion of code) ? I write 2400 dpi in genesys_sensor for lide 90. But how to know pixel number for CCD sensor ? After writing 2400 dpi in sensor, I get quarter sized images !!! Why ? With 600 dpi in sensor I get full sized images with (300dpi scanning) or without half_ccd (1200dpi scanning) (with my code for gpio 14). Regards Guillaume
[sane-devel] LiDE 90 half ccd
Hello,
Guillaume Gastebois schrieb:
Hello,
Me again !
I'm trying to find what are GPIO14,13,12 and 11 for.
I find GPIO11=home switch and must be 0.
I thought I found GPIO14 was half CCD but by adding :
/* gpio part. here: for canon lide 90 */
if (dev-model-gpo_type == GPO_CANONLIDE90)
{
r = sanei_genesys_get_address (reg, 0x6c);
if (half_ccd)
r-value |= 0x20;
else
r-value = ~0x20;
}
With code before and command scanimage, I get half sized image.
Scanimage gives me these parameters :
pixels: 2574
lines: 3531
depth: 8
channels: 1
exposure_time: 5600
xres: 300
yres: 300
half_ccd: yes
stagger: 0
max_shift: 0
Why is half ccd activated ?
I tryed with 0x1a=0x20 and it doesn't change anything. Doese it mean
that clk3 is not used ?
in genesys_gl841.c line ~2053 I had image compressed x2 in the left and
second right part black with 0x6c=12 and not with 0x6c=1a. Strange.
I decided to comment out these lines yet for tests.
In genesys_841.c I see conditions with GPO_CANONLIDE35 for gl841_feed
function (lines ~4309 and ~4913). I added GPO_CANONLIDE90 too. What is
this function for ? Is it usefull to add lide 90 ?
no, these don't help your scanner. the feed is used to position the
scanning head at the white calibration strip. This is(should not) be
needed for your scanner.
Regards
Guillaume
[sane-devel] LiDE 90
Hello,
Me again !
I'm trying to find what are GPIO14,13,12 and 11 for.
I find GPIO11=home switch and must be 0.
I thought I found GPIO14 was half CCD but by adding :
/* gpio part. here: for canon lide 90 */
if (dev-model-gpo_type == GPO_CANONLIDE90)
{
r = sanei_genesys_get_address (reg, 0x6c);
if (half_ccd)
r-value |= 0x20;
else
r-value = ~0x20;
}
in genesys_gl841.c line ~2053 I had image compressed x2 in the left and
second right part black with 0x6c=12 and not with 0x6c=1a. Strange.
I decided to comment out these lines yet for tests.
In genesys_841.c I see conditions with GPO_CANONLIDE35 for gl841_feed
function (lines ~4309 and ~4913). I added GPO_CANONLIDE90 too. What is
this function for ? Is it usefull to add lide 90 ?
tests I made were :
0x1a=00 and 0x6c=02 : bad calibration vertical lines
0x1a=00 and 0x6c=0a : bad calibration vertical lines (motor sometimes
locks at the end with noise).
0x1a=00 and 0x6c=12 : image like before (small calibration problems)
0x1a=00 and 0x6c=1a : image like before (small calibration problems)
0x1a=00 and 0x6c=22 : bad calibration vertical lines
0x1a=00 and 0x6c=2a : bad calibration vertical lines
0x1a=00 and 0x6c=32 : very good quality image but take only the half
left part of the page
0x1a=00 and 0x6c=3a : very good quality image but take only the half
left part of the page
0x1a=24 and 0x6c=02 or 0a or 12 or 1a or 22 or 2a or 32 or 3a : always
black image!
All the results can be found on :
http://ggastebois.free.fr/lide90_snoop/test_00 (for tests with 0x1a=00)
http://ggastebois.free.fr/lide90_snoop/test_24 (for tests with 0x1a=24)
The number in the tar name is the value off 0x6c. I think looking at
0x6c=32 or 3a is very interesting.
Why sane always produces black images with same 0x1a value as windows
driver
Regards
Guillaume
ps. : Pierre can you send me a sample entropy processed offset image to
see what I must obtain. Thank you.
[sane-devel] Re : LiDE 90 Half CCD
Hello,
Guillaume Gastebois schrieb:
Hello,
I see in genesys_gl841.c line 2503 :
/* gpio part. here: for canon lide 35 */
r = sanei_genesys_get_address (reg, 0x6c);
if (half_ccd)
r-value = ~0x80;
else
r-value |= 0x80;
I modified this in :
/* gpio part. here: for canon lide 35 */
if (dev-model-gpo_type == GPO_CANONLIDE35)
{
r = sanei_genesys_get_address (reg, 0x6c);
if (half_ccd)
r-value = ~0x80;
else
r-value |= 0x80;
}
/* gpio part. here: for canon lide 90 */
if (dev-model-gpo_type == GPO_CANONLIDE90)
{
r = sanei_genesys_get_address (reg, 0x6c);
if (half_ccd)
r-value |= 0x20;
else
r-value = ~0x20;
}
correct ?
Does it mean that for LiDE 35 GPIO16 is half CCD IO ? Because in LiDE 90, I
identify GPIO 14 for that.
The GPIO16 is used as half CCD IO. Correct.
Another thing : In windows snoop, only GPIO 14, 13, 12 and 11 changes state.
Is
it possible that scanner need different gpio state between calibration and
scanning (and different calibration phases) ? Where to add gpio state change
code in backend to change gpio between different phases ?
There is no way to know what GPIO 11, 12, 13 do without some experiments
(or tracing the wires on the pcb, which i advise against).
For example, one GPIO could shut off the LED drivers(thus making black
level calibration easier), another could be used to save power(as is
GPIO 9 in Canon LiDE 35).
Currently, i think the only possibly useful GPIOs for calibration and
scanning are the half ccd and the black led selectors, of which the
latter is not needed(At least my scanner does not need it, even when
doing black-level calibration on a white target).
I make test with 0x1a=0x24 and 0x16=02 (like windows snoops) making 0x6c varying
:
0x6c | description
___|_
12 | says Extremely low brightness detected..
1a | says Extremely low brightness detected..
0e | no home position detected
0a | says sometimes Extremely low brightness detected..
| or gives a black image
02 | black image
06 | no home position detected
16 | no home position detected
1e | no home position detected
I think that GPIO11 is home switch and must be 0.
After that I make test with 0x1a=0x00 and 0x16=20 (like sane yet) making 0x6c
varying :
0x6c | description
___|_
12 | image is half the width rest is black (half ccd problem ?)
| result : http://ggastebois.free.fr/lide90_snoop/test_12.zip
1a | image like others since today (total width of page calibration problem)
0a | image with vertical lines (calibration big problem see 0x6c=0x02)
02 | like 0x6c=0x0a
| result : http://ggastebois.free.fr/lide90_snoop/test_02.zip
What to conclude about that ?Half CCD problem is strange !
It only remains only fuction of GPIO12 and GPIO13.
Thank you.
Regards
Guillaume
Regards,
Pierre
Regards
Guillaume
[sane-devel] LiDE 90 Half CCD
Hello, I see in genesys_gl841.c line 2503 : /* gpio part. here: for canon lide 35 */ r = sanei_genesys_get_address (reg, 0x6c); if (half_ccd) r-value = ~0x80; else r-value |= 0x80; Does it mean that for LiDE 35 GPIO16 is half CCD IO ? Because in LiDE 90, I identify GPIO 14 for that. Another thing : In windows snoop, only GPIO 14, 13, 12 and 11 changes state. Is it possible that scanner need different gpio state between calibration and scanning (and different calibration phases) ? Where to add gpio state change code in backend to change gpio between different phases ? Thank you. Regards Guillaume
[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
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
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] sane
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 mp110 chipset : oa-1000
Hello, I write few days ago about canon mp110 and it's chipset OASIS OA-1000. Has anyone the datasheet of this component ? I can't find it. Thank you Guillaume
[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
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
[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 -- next part -- A non-text attachment was scrubbed... Name: genesys_devices.c Type: text/x-csrc Size: 24490 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20071231/d3d9eacc/attachment-0001.c
[sane-devel] No result with canon LiDE 90
Hello,
I have no result with LiDE 90. I take sane-backends CVS, and genesys in
experimental branch. Modified genesys_devices.c as followed.
scanimage -l gives me :
device `genesys:libusb:001:019' is a Canon LiDE 90 flatbed scanner
but scanimage -d genesys:libusb:001:019 toto.pnm
did noting !! grrr
Another question : is it possible to built only genesys backend (option
in configure ???) because building all backend is very long.
Thank you
My genesys_devices.c :
/** Setup table for various scanners using a Wolfson DAC
*/
static Genesys_Frontend Wolfson[] = {
{{0x00, 0x03, 0x05, 0x11}
, {0x00, 0x00, 0x00}
, {0x80, 0x80, 0x80}
, {0x02, 0x02, 0x02}
, {0x00, 0x00, 0x00}
}
,/* UMAX */
{{0x00, 0x03, 0x05, 0x03}
, {0x00, 0x00, 0x00}
, {0xc8, 0xc8, 0xc8}
, {0x04, 0x04, 0x04}
, {0x00, 0x00, 0x00}
}
,/* ST12 */
{{0x00, 0x03, 0x05, 0x21}
, {0x00, 0x00, 0x00}
, {0xc8, 0xc8, 0xc8}
, {0x06, 0x06, 0x06}
, {0x00, 0x00, 0x00}
}
,/* ST24 */
{{0x00, 0x03, 0x05, 0x12}
, {0x00, 0x00, 0x00}
, {0xc8, 0xc8, 0xc8}
, {0x04, 0x04, 0x04}
, {0x00, 0x00, 0x00}
}
,/* MD6228/MD6471 */
{{0x00, 0x03, 0x05, 0x02}
, {0x00, 0x00, 0x00}
, {0xc0, 0xc0, 0xc0}
, {0x07, 0x07, 0x07}
, {0x00, 0x00, 0x00}
}
,/* HP2400c */
{{0x00, 0x03, 0x04, 0x02}
, {0x00, 0x00, 0x00}
, {0xb0, 0xb0, 0xb0}
, {0x04, 0x04, 0x04}
, {0x00, 0x00, 0x00}
}
,/* HP2300c */
{{0x00, 0x3d, 0x08, 0x00}
, {0x00, 0x00, 0x00}
, {0xe1, 0xe1, 0xe1}
, {0x93, 0x93, 0x93}
, {0x00, 0x19, 0x06}
}
,/* CANONLIDE35 */
};
/** for setting up the sensor-specific settings:
* Optical Resolution, number of black pixels, number of dummy pixels,
* CCD_start_xoffset, and overall number of sensor pixels
* registers 0x08-0x0b, 0x10-0x1d and 0x52-0x59
*/
static Genesys_Sensor Sensor[] = {
/* UMAX */
{1200, 48, 64, 0, 10800, 210, 230,
{0x01, 0x03, 0x05, 0x07}
,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x05, 0x31, 0x2a, 0x00, 0x00,
0x00, 0x02}
,
{0x13, 0x17, 0x03, 0x07, 0x0b, 0x0f, 0x23, 0x00, 0xc1, 0x00, 0x00, 0x00,
0x00}
,
1.0, 1.0, 1.0,
NULL, NULL, NULL}
,
/* Plustek OpticPro S12/ST12 */
{600, 48, 85, 152, 5416, 210, 230,
{0x02, 0x00, 0x06, 0x04}
,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x2b, 0x08, 0x20, 0x2a, 0x00, 0x00,
0x0c, 0x03}
,
{0x0f, 0x13, 0x17, 0x03, 0x07, 0x0b, 0x83, 0x00, 0xc1, 0x00, 0x00, 0x00,
0x00}
,
1.0, 1.0, 1.0,
NULL, NULL, NULL}
,
/* Plustek OpticPro S24/ST24 */
{1200, 48, 64, 0, 10800, 210, 230,
{0x0e, 0x0c, 0x00, 0x0c}
,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x08, 0x31, 0x2a, 0x00, 0x00,
0x00, 0x02}
,
{0x17, 0x03, 0x07, 0x0b, 0x0f, 0x13, 0x03, 0x00, 0xc1, 0x00, 0x00, 0x00,
0x00}
,
1.0, 1.0, 1.0,
NULL, NULL, NULL}
,
/* MD6471 */
{1200,
48,
16, 0, 10872,
210, 200,
{0x0d, 0x0f, 0x11, 0x13}
,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0b, 0x0a, 0x30, 0x2a, 0x00, 0x00,
0x00, 0x03}
,
{0x0f, 0x13, 0x17, 0x03, 0x07, 0x0b, 0x23, 0x00, 0xc1, 0x00, 0x00, 0x00,
0x00}
,
2.38, 2.35, 2.34,
NULL, NULL, NULL}
,
/* HP2400c */
{1200,
48,
15, 0, 10872, 210, 200,
{0x14, 0x15, 0x00, 0x00}
,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xbf, 0x08, 0x3f, 0x2a, 0x00, 0x00,
0x00, 0x02}
,
{0x0b, 0x0f, 0x13, 0x17, 0x03, 0x07, 0x63, 0x00, 0xc1, 0x00, 0x00, 0x00,
0x00}
,
1.0, 1.0, 1.0,
NULL, NULL, NULL}
,
/* HP2300c */
{600,
48,
20, 0, 5454, 210, 200,
{0x16, 0x00, 0x01, 0x03}
,
{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xb7, 0x0a, 0x20, 0x2a, 0x6a, 0x8a,
0x00, 0x05}
,
{0x0f, 0x13, 0x17, 0x03, 0x07, 0x0b, 0x83, 0x00, 0xc1, 0x06, 0x0b, 0x10,
0x16}
,
2.1, 2.1, 2.1,
NULL, NULL, NULL}
,
/** for setting up the sensor-specific settings:
* Optical Resolution, number of black pixels, number of dummy pixels,
* CCD_start_xoffset, and overall number of sensor pixels
* registers 0x08-0x0b, 0x10-0x1d and 0x52-0x59
*/
/* CANOLIDE35 */
{2400,
/*TODO: find a good reason for keeping all three following variables*/
0, /*(black) 87 */
0, /* (dummy) 87 */
0, /* (startxoffset) */
20800, /*sensor_pixels */
210,
200,
{0x00, 0x00, 0x00, 0x00},
/*
{0x04, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x02, 0x00, 0x50,
0x00, 0x00, 0x00, 0x00 /* TODO(these do no harm, but may be
neccessery for CCD) */
/* },*/
/* {0x06, 0x13, 0x55, 0x02, 0x34, 0x04, 0x00, 0x02, 0x00, 0x50, */
[sane-devel] Canon LiDE 90
Hello, Has someone standalone scaning program or modified genesys backend for test. Because I successless try to modifying the backend. I can make tests. Guillaume
