[sane-devel] Epson Perfection 610 Issue with 150 dpi scan
Rainer Dorsch
rdorsch at web.de
Wed Jan 6 00:01:33 UTC 2010
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 the code,
> after line 1352.
>
> You might try to move it and see what happens.
Not sure if I got it as you asked for
rd at dell:~/SW.nobackup/sane-backends$ git diff|cat -
diff --git a/backend/epson2-ops.c b/backend/epson2-ops.c
index 20f0c6e..764b3d1 100644
--- a/backend/epson2-ops.c
+++ b/backend/epson2-ops.c
@@ -1256,28 +1256,6 @@ e2_init_parameters(Epson_Scanner * s)
s->val[OPT_TL_Y].w) / MM_PER_INCH * dpi + 0.5;
/*
- * Make sure that the number of lines is correct for color shuffling:
- * The shuffling alghorithm produces 2xline_distance lines at the
- * beginning and the same amount at the end of the scan that are not
- * useable. If s->params.lines gets negative, 0 lines are reported
- * back to the frontend.
- */
- if (s->hw->color_shuffle) {
- s->params.lines -= 4 * s->line_distance;
- if (s->params.lines < 0) {
- s->params.lines = 0;
- }
- DBG(1,
- "adjusted params.lines for color_shuffle by %d to %d\n",
- 4 * s->line_distance, s->params.lines);
- }
-
- DBG(1, "%s: %p %p tlx %f tly %f brx %f bry %f [mm]\n",
- __func__, (void *) s, (void *) s->val,
- SANE_UNFIX(s->val[OPT_TL_X].w), SANE_UNFIX(s->val[OPT_TL_Y].w),
- SANE_UNFIX(s->val[OPT_BR_X].w), SANE_UNFIX(s->val[OPT_BR_Y].w));
-
- /*
* Calculate bytes_per_pixel and bytes_per_line for
* any color depths.
*
@@ -1356,6 +1334,28 @@ e2_init_parameters(Epson_Scanner * s)
}
/*
+ * Make sure that the number of lines is correct for color shuffling:
+ * The shuffling alghorithm produces 2xline_distance lines at the
+ * beginning and the same amount at the end of the scan that are not
+ * useable. If s->params.lines gets negative, 0 lines are reported
+ * back to the frontend.
+ */
+ if (s->hw->color_shuffle) {
+ s->params.lines -= 4 * s->line_distance;
+ if (s->params.lines < 0) {
+ s->params.lines = 0;
+ }
+ DBG(1,
+ "adjusted params.lines for color_shuffle by %d to %d\n",
+ 4 * s->line_distance, s->params.lines);
+ }
+
+ DBG(1, "%s: %p %p tlx %f tly %f brx %f bry %f [mm]\n",
+ __func__, (void *) s, (void *) s->val,
+ SANE_UNFIX(s->val[OPT_TL_X].w), SANE_UNFIX(s->val[OPT_TL_Y].w),
+ SANE_UNFIX(s->val[OPT_BR_X].w), SANE_UNFIX(s->val[OPT_BR_Y].w));
+
+ /*
* Modify the scan area: If the scanner requires color shuffling, then
we try to
* scan more lines to compensate for the lines that will be removed
from the scan
* due to the color shuffling alghorithm.
rd at dell:~/SW.nobackup/sane-backends$
That change did not help though, I think that is exactly the old behaviour.
rd at dell:~/SW.nobackup/sane-backends$ cd
rd at dell:~$ scanimage -d 'epson2:libusb:001:003' --mode='Color' -y 297 -l
0 --resolution='150' -x 210 -t 0 -v > test150.pnm
scanimage: scanning image of size 1240x1754 pixels at 24 bits/pixel
scanimage: acquiring RGB frame
scanimage: min/max graylevel value = 38/255
scanimage: read 6510000 bytes in total
rd at dell:~$ convert test150.pnm test150.png
convert: unable to read image data `test150.pnm'.
convert: missing an image filename `test150.png'.
rd at dell:~$ pnmtopng test150.pnm > test150.png
pnmtopng: EOF / read error reading a row of pixels
rd at dell:~$ which scanimge
rd at dell:~$ which scanimage
/opt/sane-backends-100106/bin/scanimage
rd at dell:~$
I rescanned with DBG Information. Now I find in there
[epson2] e2_check_adf
[epson2] adjusted params.lines for color_shuffle by 8 to 1746
[epson2] e2_init_parameters: 0x8688ef0 0x8689430 tlx 0.000000 tly 0.000000 brx
210.000000 bry 297.000000 [mm]
[epson2] max req size: 131072
complete file with debug output is at http://bokomoko.de/~rd/test150.dbg.bz2
[upload needs another 10 minutes to complete]
Since we calculated 1750 lines are scanned (from the total bytes numbers), I
modified
s->params.lines -= 4 * s->line_distance;
to
s->params.lines -= 2 * s->line_distance;
which results in exactly the 1750 lines....but the pnm is still corrupted.
Seems more thought needs to go into this....
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 bytes are then really read? worth of 1758 lines???
Just random thoughts since I do not really understand what is going on
there....
Thanks,
Rainer
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch at web.de
jabber: rdorsch at jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20100106/cbbe57f2/attachment-0001.pgp>
More information about the sane-devel
mailing list