Hi Alessandro and Olaf,
thanks for the patch.
Am Freitag, 8. Januar 2010 schrieb Alessandro Zummo:
On Fri, 8 Jan 2010 00:25:54 +0100
Rainer Dorsch rdorsch at web.de wrote:
will can do more tests on the weekend. Is there something you would
consider of high value? Varying resolutions?
On Sun, 10 Jan 2010 00:36:19 +0100
Rainer Dorsch rdorsch at web.de wrote:
I applied the patch, build, and tested all supported color resolutions (75,
150, 300, 600). I list below how many lines where requested, what the backend
requested, and what the scanner really scanned:
Thanks for
Hi Alessandro,
Am Mittwoch, 6. Januar 2010 schrieb Alessandro Zummo:
On Wed, 6 Jan 2010 22:30:23 +0100
Rainer Dorsch rdorsch at web.de wrote:
Did you forget to add a new patch or do you think the old one compensates
already for the 8 lines?
The backend does some compensation, but a few
Alessandro Zummo wrote:
On Sun, 3 Jan 2010 15:14:38 +0100
Rainer Dorsch rdorsch at web.de wrote:
Are these the areas in epson2.c you are refering to:
/*
* Make sure that the number of lines is correct for color shuffling:
* The shuffling alghorithm produces
On Fri, 08 Jan 2010 14:06:54 +0900
Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote:
That code does the wrong thing. The epkowa backend fixed the
s.params-lines calculations in, eh, iscan-1.14.0 (released in 2005).
Search epkowa.c of a recent iscan for finalise the number of scanlines
to
Alessandro,
Am Sonntag, 3. Januar 2010 schrieb Alessandro Zummo:
On Sun, 3 Jan 2010 19:09:56 +0100
Rainer Dorsch rdorsch at web.de wrote:
Can you point me to the locations in the code?
I believe the bug lies in line 1260 of epson2-ops.c .
The code block should probably happen later in
On Tue, 5 Jan 2010 20:29:40 -0500
m. allan noah kitno455 at gmail.com wrote:
I cannot comment on the specific limitations of this scanner, but this
kind of issue used to be common, but now only happens with cheap
scanners. The machine's RGB channels are not read from the same row at
the same
Hi Alessandro,
Am Mittwoch, 6. Januar 2010 schrieben Sie:
On Tue, 5 Jan 2010 20:29:40 -0500
m. allan noah kitno455 at gmail.com wrote:
I cannot comment on the specific limitations of this scanner, but this
kind of issue used to be common, but now only happens with cheap
scanners. The
On Wed, 6 Jan 2010 17:46:46 +0100
Rainer Dorsch rdorsch at web.de wrote:
I believe Allan is right. Rainer, did you tried with
the epson driver?
I had the same thought :-)
The git version von epson has the same issue. The 651 bytes correspond to
1750 lines.
at least I ported it
Alessandro,
many thanks for your quick reply.
Am Mittwoch, 6. Januar 2010 schrieben Sie:
On Wed, 6 Jan 2010 18:44:18 +0100
Rainer Dorsch rdorsch at web.de wrote:
I'm attaching a patch, please test with
epson2 debug level 11
I did a
git reset HEAD --hard
to get rid of my local
Am Mittwoch, 6. Januar 2010 schrieben Sie:
On Wed, 6 Jan 2010 21:51:08 +0100
Rainer Dorsch rdorsch at web.de wrote:
Seems now we are scanning 8 lines less than the requested 1754:
[epson2] written 1746 lines after color shuffle
[epson2] lines requested: 1746
Should we compensate for
On Wed, 6 Jan 2010 22:30:23 +0100
Rainer Dorsch rdorsch at web.de wrote:
Did you forget to add a new patch or do you think the old one compensates
already for the 8 lines?
The backend does some compensation, but a few lines are lost
anyhow. Yoo might try to understand how the algorithm
snip
Alessandro, do you know why the color shuffling algorithm is there?
Why are lines from the beginning and the end removed?
If the input is 1754 lines, would we then expect that more sould be scanned
(e.g. 1762) and the we remove 4 at the beginning and the end respectively?
And how many
Hi Allan,
I was not aware that there is an epson2 backend, thanks for pointing that out.
You are right, twelve pixels rows are missing in the final result compared to
the epson2 backend prediction. I try to play with the y parameter this
afternoon. I would be surprised though if that would be
On Sun, 3 Jan 2010 14:01:15 +0100
Rainer Dorsch rdorsch at web.de wrote:
I was not aware that there is an epson2 backend, thanks for pointing that
out.
You are right, twelve pixels rows are missing in the final result compared to
the epson2 backend prediction. I try to play with the y
Hi Alessandro,
thank you for the quick reply.
Am Sonntag, 3. Januar 2010 schrieb Alessandro Zummo:
On Sun, 3 Jan 2010 14:01:15 +0100
Rainer Dorsch rdorsch at web.de wrote:
I was not aware that there is an epson2 backend, thanks for pointing that
out. You are right, twelve pixels rows are
On Sun, 3 Jan 2010 15:14:38 +0100
Rainer Dorsch rdorsch at web.de wrote:
Are these the areas in epson2.c you are refering to:
/*
* Make sure that the number of lines is correct for color shuffling:
* The shuffling alghorithm produces 2xline_distance lines at the
Hello,
thanks, I run with SANE_DEBUG_EPSON2=255. The debug message and image data
seem to go both the stdout:
http://www.bokomoko.de/~rd/test150.pnm.bz2
What I found interesting is that s-hw-color_shuffle seems to be false
if (s-hw-color_shuffle) {
s-params.lines -= 4
There are multiple fixes for this, but at bare minimum, the driver
should output more lines of white data.
allan
On Sun, Jan 3, 2010 at 1:09 PM, Rainer Dorsch rdorsch at web.de wrote:
Hello,
thanks, I run with SANE_DEBUG_EPSON2=255. The debug message and image data
seem to go both the
On Sun, Jan 3, 2010 at 7:01 AM, Rainer Dorsch rdorsch at web.de wrote:
For the long options issue:
I rebuild git sane on another machine (also Debian stable aka Debian 5.0)
and
the long options error is still there. Even --help has problems. Which
library is sane using to process the
On Sun, 3 Jan 2010 19:09:56 +0100
Rainer Dorsch rdorsch at web.de wrote:
Can you point me to the locations in the code?
I believe the bug lies in line 1260 of epson2-ops.c .
The code block should probably happen later in the code,
after line 1352.
You might try to move it and see what
Allan,
(cc'ed Karl Heinz since he is listed as epson backend author)
I used latest git code now.
rd at dell:~$ scanimage --version
scanimage (sane-backends) 1.0.21cvs; backend version 1.0.21
rd at dell:~$
The first thing I noticed is that the code has issues with long-format
options:
rd at
It appears that the image is 12 lines short of what the backend
initially indicated. You might try tweaking the -y parameter by a
fraction of a millimeter, and see if the problem stops. perhaps the
epson2 backend author might have an idea...
I cannot replicate your long option errors?
allan
On
Thanks for the quick reply. I built from git, but can test only tomorrow with
the scanner.
I am wondering if I can have two sane-backends installations in parallel while
testing. I did a ./configure prefix=/opt/sane-backends-091230 and then a
rd at blackbox:~/SW.nobackup/sane-backends$ .
24 matches
Mail list logo
