[sane-devel] LiDE 90
pierre at pirsoft.dnsalias.org
Thu Apr 17 13:02:38 UTC 2008
Guillaume Gastebois schrieb:
> 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;
> 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 ?
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.
> 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 ????
Because the rest of the clock registers are setup incorrectly. This
probably leads to the CCD bar not getting correct pulses to move the
electrical charges. No charge means black pixel. It should be possible
to simulate the behavior when the clock generators are switched to
"automatic", but this default behavior is not well documented.
> ps. : Pierre can you send me a sample entropy processed offset image to
> see what I must obtain. Thank you.
Attached is the result of the dark part of a shading calibration run.
When doing offset calibration, most of the time i only see a single
line(sometimes with a wraparound into the next line).
Note that the image is nearly symmetrical to the diagonal axis, meaning
two consecutive bytes are uncorrelated. The result of the white part
shows a larger band, typical around 20 pixels width, but with a lot of
speckles(which is in no way an indicator of problems).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1997 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080417/bc0a379c/attachment.png
More information about the sane-devel