[sane-devel] Canon LiDE 20 vertical lines

[Udo Lütkemeier]

Hello,

i have bought a new Canon LiDE 20.
I have me decide for these Scanner, because these is list on the website
from the sane-project with status "complete". Also have another LiDE 20
user from the ELUG(Essener Linux User Group) send me demo-scans.
These scans have also a good quality.

Yesterday, i have install the Scanner on Debian etch(testing) with
follow sane version:

$ scanimage --version
scanimage (sane-backends) 1.0.15; backend version 1.0.15

The Scanner runs also, only the quality is under Linux bad.
The pictures have dark vertical lines through the scans. :-(

I have make test scans, that you can see these vertical lines. Please
follow the links to the testscans below.

The lines are not on the glass plate of the scanner and not on the
original photos.

Yesterday, i have try adjust the settings in xsane. These adjust was of
no avail. :-(

Now, i have these scanner install on windows. There are no vertical
lines in the scans. See the links to my testscans below.

I have yesterday also tested the latest snapshot of sane-backends. With
these, there was the same dark vertical lines.

How can I remove the dark vertical lines in the scans on linux?

Why are these lines not at the demo-scans of the other LiDE 20 user
from the ELUG on Linux?

Where do the dark vertical lines come from and why are they not on
windows?

Testscans(please zoom in, that you can better see the lines):

- Testscans with dark vertical lines on Linux:

Loading Image...
Loading Image...

- Testscans without dark vertical lines on Windows:

Loading Image...
Loading Image...

- Testscan without dark vertical lines from another LiDE 20 user from
the ELUG on Linux:

Loading Image...

System information:

OS: Debian GNU/Linux etch(testing)
CPU: Intel P4 2.8 GHz
RAM: 1024 MB

$ uname -r
2.6.8-2-686-smp

sane version:
$ scanimage --version
scanimage (sane-backends) 1.0.15; backend version 1.0.15

Scanner:
$ scanimage -L
device `plustek:libusb:005:008' is a Canon N670U/N676U/LiDE20 USB
flatbed scanner

$ sane-find-scanner
[...]
found USB scanner (vendor=0x04a9 [Canon], product=0x220d [CanoScan],
chip=LM9832/3) at libusb:005:008
[...]

With best regards,

Udo Lütkemeier

[Gian Domeni Calgeer]

Hmm... This seems to be a common problem, maybe a bug in sane (see
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014006.html,
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014018.html,
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014019.html,
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014020.html)

Post by Udo Lütkemeier
Hello,
i have bought a new Canon LiDE 20.
I have me decide for these Scanner, because these is list on the website
from the sane-project with status "complete". Also have another LiDE 20
user from the ELUG(Essener Linux User Group) send me demo-scans.
These scans have also a good quality.
Yesterday, i have install the Scanner on Debian etch(testing) with
$ scanimage --version
scanimage (sane-backends) 1.0.15; backend version 1.0.15
The Scanner runs also, only the quality is under Linux bad.
The pictures have dark vertical lines through the scans. :-(
I have make test scans, that you can see these vertical lines. Please
follow the links to the testscans below.
The lines are not on the glass plate of the scanner and not on the
original photos.
Yesterday, i have try adjust the settings in xsane. These adjust was of
no avail. :-(
Now, i have these scanner install on windows. There are no vertical
lines in the scans. See the links to my testscans below.
I have yesterday also tested the latest snapshot of sane-backends. With
these, there was the same dark vertical lines.
How can I remove the dark vertical lines in the scans on linux?
Why are these lines not at the demo-scans of the other LiDE 20 user
from the ELUG on Linux?
Where do the dark vertical lines come from and why are they not on
windows?
http://www.udo-luetkemeier.de/temp/Schnee-Linux.jpg
http://www.udo-luetkemeier.de/temp/Berge-Linux.jpg
http://www.udo-luetkemeier.de/temp/Schnee-Win.jpg
http://www.udo-luetkemeier.de/temp/Berge-Win.jpg
- Testscan without dark vertical lines from another LiDE 20 user from
http://www.udo-luetkemeier.de/temp/out0003.jpg
OS: Debian GNU/Linux etch(testing)
CPU: Intel P4 2.8 GHz
RAM: 1024 MB
$ uname -r
2.6.8-2-686-smp
$ scanimage --version
scanimage (sane-backends) 1.0.15; backend version 1.0.15
$ scanimage -L
device `plustek:libusb:005:008' is a Canon N670U/N676U/LiDE20 USB
flatbed scanner
$ sane-find-scanner
[...]
found USB scanner (vendor=0x04a9 [Canon], product=0x220d [CanoScan],
chip=LM9832/3) at libusb:005:008
[...]
With best regards,
Udo Lütkemeier
--
Udo Lütkemeier http://www.udo-luetkemeier.de
GPG Key-ID: 0xB234C956 Public key available on my website.
Key fingerprint = 6827 CC47 6ADE 124B B81A 32E3 00BB FF25 B234 C956

[Gerhard Jaeger]

Hi,

Post by Gian Domeni Calgeer
Hmm... This seems to be a common problem, maybe a bug in sane (see
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014006.html,
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014018.html,
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014019.html,
http://lists.alioth.debian.org/pipermail/sane-devel/2005-July/014020.html)

Post by Udo Lütkemeier
Hello,
i have bought a new Canon LiDE 20.
I have me decide for these Scanner, because these is list on the website
from the sane-project with status "complete". Also have another LiDE 20
user from the ELUG(Essener Linux User Group) send me demo-scans.
These scans have also a good quality.

[SNIPSNAP]

it's definitly not a SANE bug - it's a problem in fine calibration - if the position
of the fine-calibration strip is not excactly set, you might get those stripes - some
backends tryy to find it automagically, some set them directly.

For the plustek-backend, you might want to test with various values for
posShadingY (to set in the options section in plustek.conf), try values from 10 to 50...
and make sure to use the latest CVS snapshot - enable debug and try a scan, i.e.:
export SANE_DEBUG_PLUSTEK=19 ; xsane - send us the output.

Ciao,
Gerhard

[Udo Lütkemeier]

Hi Gerhard,

Post by Gerhard Jaeger
it's definitly not a SANE bug - it's a problem in fine calibration - if the position
of the fine-calibration strip is not excactly set, you might get those stripes - some
backends tryy to find it automagically, some set them directly.
For the plustek-backend, you might want to test with various values for
posShadingY (to set in the options section in plustek.conf), try values from 10 to 50...
export SANE_DEBUG_PLUSTEK=19 ; xsane - send us the output.

thanks for your answer.
Now, i have test posShadingY with various values from 10 to 50. The
value 40 have a little bit reduce the vertical lines in the scans, but
this option don't remove the extreme lines in my scans. Option 40 have
from values 10 to 50 best the "best" result.

Output(very long) from "export SANE_DEBUG_PLUSTEK=19 ; xsane":

http://www.udo-luetkemeier.de/temp/xsane.log

The picture from this scan(please zoom in):

Loading Image...

This scan was made with following version:

sane-backends-2005-08-02.tar.gz

Then, I have this detected:

When I make with xsane a empty scan, I can better see the vertical
lines. The following picture was the result of a scan with these
settings in xsane:

"XSane mode" "Save",
"Color",
"Full color range",
"testscan.jpeg",
Step "+1",
Type "JPEG",
resolution "300" dpi,
gamma "0.30",
brightness "-100.0",
contrast "100.0"

With these stettings, you can best see the lines without a
picture/document.

Loading Image...

Are the lines in testscan.jpeg normal or are this lines also _the_
lines of my other scans?

With best regards,

Udo Lütkemeier

[Gerhard Jaeger]

Hi,

Post by Udo Lütkemeier
Hi Gerhard,

Post by Gerhard Jaeger
it's definitly not a SANE bug - it's a problem in fine calibration - if the position
of the fine-calibration strip is not excactly set, you might get those stripes - some
backends tryy to find it automagically, some set them directly.
For the plustek-backend, you might want to test with various values for
posShadingY (to set in the options section in plustek.conf), try values from 10 to 50...
export SANE_DEBUG_PLUSTEK=19 ; xsane - send us the output.

thanks for your answer.
Now, i have test posShadingY with various values from 10 to 50. The
value 40 have a little bit reduce the vertical lines in the scans, but
this option don't remove the extreme lines in my scans. Option 40 have
from values 10 to 50 best the "best" result.

;)

Post by Udo Lütkemeier
http://www.udo-luetkemeier.de/temp/xsane.log
http://www.udo-luetkemeier.de/temp/scan_with_sane-cvs.jpeg
sane-backends-2005-08-02.tar.gz
When I make with xsane a empty scan, I can better see the vertical
lines. The following picture was the result of a scan with these
"XSane mode" "Save",
"Color",
"Full color range",
"testscan.jpeg",
Step "+1",
Type "JPEG",
resolution "300" dpi,
gamma "0.30",
brightness "-100.0",
contrast "100.0"
With these stettings, you can best see the lines without a
picture/document.
http://www.udo-luetkemeier.de/temp/testscan.jpeg
Are the lines in testscan.jpeg normal or are this lines also _the_
lines of my other scans?

these are the lines that should not appear :(
I've done some tests here with a LiDE30 and there were no lines, then I
connected the N670 (which should be the same device as the LiDE20) and
I see also these damned lines - I don't know currently where the problem
is - I have to do some more testing.

Ciao,
Gerhard

[Udo Lütkemeier]

Hi Gerhard,

Post by Gerhard Jaeger
these are the lines that should not appear :(
I've done some tests here with a LiDE30 and there were no lines, then I
connected the N670 (which should be the same device as the LiDE20) and
I see also these damned lines - I don't know currently where the problem
is - I have to do some more testing.

I hope, you find the problem/error and can solve it in the next
releases.

Please let me and the LiDE20/N670 user know here, when the problem is
located or solved.

With best regards,

Udo Lütkemeier

[Monty]

Post by Udo Lütkemeier
Hi Gerhard,

Post by Gerhard Jaeger
these are the lines that should not appear :(
I've done some tests here with a LiDE30 and there were no lines, then I
connected the N670 (which should be the same device as the LiDE20) and
I see also these damned lines - I don't know currently where the problem
is - I have to do some more testing.

I hope, you find the problem/error and can solve it in the next
releases.
Please let me and the LiDE20/N670 user know here, when the problem is
located or solved.

I have a LiDE20 and was the person who originally 'completed' the
driver support. Vertical lines are indeed a fine calibration problem
and after I fixed the original nonfunctional code, fine calibration
has been broken again several times. Apparently it has been broken
yet again; I got tired of it breaking all the time and nailed my
package system to hold the installed version at 1.0.13, which I knew
to work properly.

Honestly, I don't have the time to fix this for the third time.... Is
there any kind of regression testing going on? I know it's hard to
maintain a driver for diverse, low-end hardware families, OTOH, this
is getting a little ridiculous. LiDE fine cal is broken more often
than it's working. Having one driver trying to serve fifty different
models across a family of ten related chips is unworkable when changes
to any one model break ten others that can't even be tested because
the author doesn't own the hardware to do the testing.

I'll put up the last LiDE20 driver (which works: I'm still using it) I
contributed as soon as the machine it's on is on the Net again (just
moved to a new house, IT there is in disarray).

Monty

[Gerhard Jaeger]

Hi Monty,

Post by Monty

Post by Udo Lütkemeier
Hi Gerhard,

Post by Gerhard Jaeger
these are the lines that should not appear :(
I've done some tests here with a LiDE30 and there were no lines, then I
connected the N670 (which should be the same device as the LiDE20) and
I see also these damned lines - I don't know currently where the
problem is - I have to do some more testing.

I hope, you find the problem/error and can solve it in the next
releases.
Please let me and the LiDE20/N670 user know here, when the problem is
located or solved.

I have a LiDE20 and was the person who originally 'completed' the
driver support. Vertical lines are indeed a fine calibration problem
and after I fixed the original nonfunctional code, fine calibration
has been broken again several times. Apparently it has been broken
yet again; I got tired of it breaking all the time and nailed my
package system to hold the installed version at 1.0.13, which I knew
to work properly.

I really appreciate your work and was happy that someone fixed this
issue at least for the LiDE20, but I could not accept this: "broken
several times..." - If the code is broken before a new SANE version
will be released, I'd like to have some feedback not any complaints
AFTER code-freeze, that's the way the show works.

Post by Monty
Honestly, I don't have the time to fix this for the third time.... Is
there any kind of regression testing going on? I know it's hard to
maintain a driver for diverse, low-end hardware families, OTOH, this
is getting a little ridiculous. LiDE fine cal is broken more often
than it's working. Having one driver trying to serve fifty different
models across a family of ten related chips is unworkable when changes
to any one model break ten others that can't even be tested because
the author doesn't own the hardware to do the testing.

That's indeed more or less impossible. I own the N670 which should be
more or less the same as the LiDE20, but I could not test every single
device before a release takes place - I need feedback from others.

Post by Monty
I'll put up the last LiDE20 driver (which works: I'm still using it) I
contributed as soon as the machine it's on is on the Net again (just
moved to a new house, IT there is in disarray).

So you're still working with SANE-1.0.13? Is 1.0.14 also broken? In the
end the differences to 1.0.13 are not that large. I'll submit a patch
probably this evening and you're welcome to cross-check. What about the
pictures from 1.0.13? Aren't those too dark?

As I already said criticism is a good thing, as long as it is constructive!

Ciao,
Gerhard

[Monty]

Post by Gerhard Jaeger
I really appreciate your work and was happy that someone fixed this
issue at least for the LiDE20, but I could not accept this: "broken
several times..." - If the code is broken before a new SANE version
will be released, I'd like to have some feedback not any complaints
AFTER code-freeze, that's the way the show works.

I'm sorry, I should be fair here: It's not clear that this isn't a
packaging or versioning problem in Debian. However, both the .14 and
.15 releases are broken here (in different ways).

Post by Gerhard Jaeger
That's indeed more or less impossible. I own the N670 which should be
more or less the same as the LiDE20, but I could not test every single
device before a release takes place - I need feedback from others.

Agreed; although I was venting I didn't mean to lay blame. It is, in
fact, impossible for any developer to guarantee proper funcion on 50
models. I tired to do this myself long ago with cdparanoia, and
didn't really succeed either.

Post by Gerhard Jaeger
So you're still working with SANE-1.0.13? Is 1.0.14 also broken? In the
end the differences to 1.0.13 are not that large.

Yes, but--- I'll bet real money that Debian's .14 is not a clean .14.

I can't look into more detail right now. I just moved to a new [which
is to say, very old] house myself, and my LiDE are still packed up
(of all the silly things, there are no grounded outlets in the whole
house, so I can't plug in my desktop yet!)

Monty

[Julien BLACHE]

Post by Monty
I'm sorry, I should be fair here: It's not clear that this isn't a
packaging or versioning problem in Debian. However, both the .14 and
.15 releases are broken here (in different ways).

You know, we have a fair number of users. When a scanner, especially a
recent one like the LiDE 20 breaks, we get a bug report in under a
week.

Post by Monty
Yes, but--- I'll bet real money that Debian's .14 is not a clean .14.

1.0.14 didn't contain a lot of patches. Most of the patches were not
affecting backends.

1.0.15 had a couple of patches for different backends, mainly because
1.0.16 took so long to release. There indeed was a patch for the
plustek backend in 1.0.15; I pulled the backend from CVS after Gerhard
made some fixes for the Epson Perfection 1260.

See for yourself:
<http://svn.technologeek.org/cgi-bin/viewcvs.cgi/SANE/sane-backends/tags/?root=debian>

Look in debian/patches for each tagged release.


I don't like the accusations you're making. This is not $RANDOM_DISTRO
here with $RANDOM_MAINTAINER applying $RANDOM_PATCHES.

I've been maintaining SANE in Debian together with Aurélien Jarno for
more than 2 years now. We are reading sane-devel on a daily basis at
least, and hang out on #sane permanently. Whenever something happens,
we're here to help.

Whenever an important patch or new functionality pops up in the CVS, I
mark the commit mail and wait a few days to see how things go. If
things go well, I pull the backend from CVS. (I tend to be the one
pulling new functionalities into the package) When this happens, this
backend is on my radar and I track each and every CVS commit affecting
it.

When we have fixes or get a bug report, we react immediately and
propagate it to either this mailing-list or the CVS ASAP.


I spent some time assembling the sane-backends-extras source package
to collect as many (mostly) stable external backends as possible. It's
intended for use outside of Debian too, and I know it's being
used. The result of that is that the hp4200 backend is back from the
dead and just made it to the CVS.

Our goal is to provide to our users the best scanning experience they
could possibly have. And judging by the feedback we receive, we're
doing a great job. Today, scanning on Debian with any recent scanner
works *out of the box* for all USB scanners (of course not the ones
requiring a firmware, but that's trivial); PP scanners tend to work
great too, SCSI scanners are, well, SCSI scanners with all the
associated troubles.


Want more ? Aurélien took over the maintenance of libusb in
Debian, only because it is used by SANE and we wanted to have as much
control as possible over our dependencies, especially the critical
ones. And it proved to be a good idea.


So now, next time you'll have a problem with our packages, you'll
learn to either mail us or use reportbug in due time.

Until then, shut up. And I mean it. If you had quality problems with
1.0.14 or 1.0.15 Debian packages, you should have reported that back
then.

Go look at the state of SANE in other distros. Two years ago, I took a
look at the SANE packages of every single distro out of there, looking
for useful patches to integrate. The result ? Nothing. All I saw was a
dirty, unmaintained pile of hacks, badly written RPM specfiles, buggy
scripts, dangerous patches.

Sadly, this situation hasn't evolved much.

JB.

[Monty]

Post by Julien BLACHE
I don't like the accusations you're making. This is not $RANDOM_DISTRO
here with $RANDOM_MAINTAINER applying $RANDOM_PATCHES.

The packages, as installed on my machine were, broken. The source I
rolled by hand for pre-.13 were not. There was a brief period when
the shipped package worked. I'm accusing nobody of anything other
than 'at some point things broke'. Oh, I suppose I've also stated
"...and it doesn't surprise me" for various reasons that don't involve
anyone's personal failings.

There is a development/support model problem (not a huge one, but one
that is breaking previously orking software) and I am frustrated by
that. I want working things to stay working. The *hardware* hasn't
changed any.

Post by Julien BLACHE
Until then, shut up. And I mean it. If you had quality problems with
1.0.14 or 1.0.15 Debian packages, you should have reported that back
then.

Fine, I'll shut up then. It's my time and I'm uninterested in waving
dicks. I wrote the code and that original code still works great for
me. The rest of you can figure it out on your own. My scanner works.

Terribly sorry for the offense.

Monty