[sane-devel] Epson Perfection 610 Issue with 150 dpi scan

m. allan noah kitno455 at gmail.com
Sun Jan 3 19:37:37 UTC 2010


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 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 * 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(5, "resolution = %d, preview = %d\n",
>            s->val[OPT_RESOLUTION].w, s->val[OPT_PREVIEW].w);
>
> since the "adjusted params.lines" does not show in the log:
>
> [epson2] main = 01, ADF = 00, TPU = 00, main 2 = 00
> [epson2] sane_epson2_start: scanning...
> [epson2] e2_start_std_scan
> [epson2] e2_send: size = 2, reply = 126486
> [epson2] e2_send: ESC G
> [epson2] buf[0] 1b .
> [epson2] buf[1] 47 G
> [epson2] e2_send: cmd count, r = 40, w = 37
> [epson2] sane_epson2_get_parameters
> [epson2] returning saved params structure
> [epson2] restoring parameters from saved parameters
> [epson2] resolution = 150, preview = 0
> [epson2] get para tlx 0.000000 tly 0.000000 brx 210.000000 bry 297.000000 [mm]
> [epson2] params.format          = 1
> [epson2] params.last_frame      = 1
> [epson2] params.bytes_per_line  = 3720
> [epson2] params.pixels_per_line = 1240
> [epson2] params.lines           = 1754
> [epson2] params.depth           = 8
>
> Here it seem that the number of lines 1754 (=297/25.4*150) is still ok.
>
> Later epson2 reports:
> [epson2] e2_block_sane_read: begin
> [epson2] written 1750 lines after color shuffle
> [epson2] lines requested: 1754
> [epson2] moving data 32768 0x8ca6d18 0x8ca6d18
>
> This seems to be the 4 lines of discrepance (the 12 lines Allan and me
> mentioned before were wrong, it is 3 byte per pixel).
>
> The debug code from above comes from here (epson2-ops.c)
>
>                if (s->eof) {
>                        if (s->hw->color_shuffle) {
>                                DBG(1,
>                                    "written %d lines after color shuffle\n",
>                                    s->lines_written);
>                                DBG(1, "lines requested: %d\n",
>                                    s->params.lines);
>                        }
>
>                        return SANE_STATUS_EOF;
>                }
>
> Is it correct that the epson2 backend
> -> requests the scanner to scan 1754 lines
> -> it acctually only scanned 1750 lines
>
> This mismatch is in the pnm file. Is the 1754 written before we start
> scanning, i.e. the backend needs to predict the correct number of lines the
> scanner scans?
>
> Can you point me to the locations in the code?
>
> Thanks,
> Rainer
>
> Am Sonntag, 3. Januar 2010 schrieb Alessandro Zummo:
>> 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 * 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(5, "resolution = %d, preview = %d\n",
>> >             s->val[OPT_RESOLUTION].w, s->val[OPT_PREVIEW].w);
>> >
>> >         DBG(5, "get para %p %p tlx %f tly %f brx %f bry %f [mm]\n",
>> >             (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));
>> >
>> > and
>> >
>> >         /* allocate buffers for color shuffling */
>> >         if (dev->color_shuffle == SANE_TRUE) {
>> >                 int i;
>> >                 /* initialize the line buffers */
>> >                 for (i = 0; i < s->line_distance * 2 + 1; i++) {
>> >
>> >                         if (s->line_buffer[i] != NULL)
>> >                                 free(s->line_buffer[i]);
>> >
>> >                         s->line_buffer[i] =
>> > malloc(s->params.bytes_per_line); if (s->line_buffer[i] == NULL) {
>> >                                 DBG(1, "out of memory (line %d)\n",
>> > __LINE__); return SANE_STATUS_NO_MEM;
>> >                         }
>> >                 }
>> >         }
>> >
>> > I think a first good step would be to enable debug output.
>> >
>> > How can I enable the output in DBG() from scanimage ?
>>
>>  Those are two of the involved sections. However I did not wrote
>> them so I can just hope they work nicely ;)
>>
>>  You can enable debug with SANE_DEBUG_EPSON2=XX
>> where XX is a value between 1 and 255.
>>
>>  Thanks for the remote access offer but I'll be quite busy for the
>>  forthcoming weeks :(
>>
>> > >  For such a scanner, I'd suggest to scan a bigger area
>> > > and then refine by software.
>> >
>> > I to now worry a lot about the 2-3 mm missing in the scan (12 lines at
>> > 150dpi), the problem is that the pnm file is broken and most programs
>> > reject to work with it. E.g. gscan2pdf uses convert from imagemagick to
>> > generate pdfs. But that all only works it the pnm files are correct and
>> > not corrupted. For me a fix which at least generates correct pnm files
>> > would be fine.
>>
>>  Did you tried other scanning software?
>
>
>
> --
> 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/
>



-- 
"The truth is an offense, but not a sin"



More information about the sane-devel mailing list