Re: [gscan2pdf-help] Resolution options with Epson Workforce 645 all in one

[Jim M. <ji...@pe...>]

Hi Jeff,

I've done a bit more investigation and looked at both the epson2 and epkowa
sources as well as the "iscan" front end. There's some strange code there.

ISCAN FRONT END:

The "iscan" front end appears to hard code the resolution to its own set of
values, many of which don't appear in the list at all. For example, iscan
presents 72 dpi and 96 dpi, but not 75 dpi which is what the log files
indicate the back end returns. Somehow the image gets scaled appropriately,
I'm not sure where.

EPSON2 BACK END:

The debug log files indicate that, in my configuration, the epson2 back end
doesn't think it can get the resolution list and so, arbitrarily, decides
to report "75|100|150|300|600|1200|2400dpi". It's a little odd, because the
epkowa back end gets the (slightly bogus) resolution values back from the
scanner just fine, but that's what the code is doing.

EPKOWA BACK END:

The epkowa back end really is getting the "75|300|1200|2400dpi" values
directly from the printer, so it looks like the bug may really be in the
firmware. I doubt it will ever get fixed, even if I could figure out who to
report the problem to.

What I was able to do was build a modified version of the epkowa back end
that inserts "missing" values into resolution strings. It's not elegant,
but it works well enough for now.

At this point, except for some odd behavior around duplex scanning, page
rotation, and saved profiles (which I can work around), things are working
great. I'll try to put together a coherent description of the remaining
issues I'm seeing and send them as a separate note.

Thanks for your help. If you decide to add support for "x-resolution" and
"y-resolution" I remain more than happy to test them for you with the Epson
645.

Jim

On Fri, Mar 10, 2017 at 1:59 PM, Jim Mayer <ji...@pe...> wrote:

> Hi Jeff,
>
> Here's the info you requested:
>
> [jmayer@bigbrick out]$ scanimage --x-resolution 150 --y-resolution 150
> --resolution 75 --format tiff > scan001.tif
> [jmayer@bigbrick out]$ scanimage --y-resolution 300 --resolution 75
> --x-resolution 150 --format tiff > scan002.tif
> [jmayer@bigbrick out]$ scanimage --resolution 75 --x-resolution 150
> --y-resolution 300 --format tiff > scan003.tif
> [jmayer@bigbrick out]$ tiffinfo scan*.tif
> scan001.tif:
> TIFF Directory at offset 0x8 (8)
>   Subfile Type: (0 = 0x0)
>   Image Width: 632 Image Length: 877
>   Resolution: 75, 75 pixels/inch
>   Bits/Sample: 8
>   Compression Scheme: None
>   Photometric Interpretation: RGB color
>   Orientation: row 0 top, col 0 lhs
>   Samples/Pixel: 3
>   Rows/Strip: 877
>   Min Sample Value: 0
>   Max Sample Value: 255
>   Planar Configuration: single image plane
> scan002.tif:
> TIFF Directory at offset 0x8 (8)
>   Subfile Type: (0 = 0x0)
>   Image Width: 1272 Image Length: 877
>   Resolution: 75, 75 pixels/inch
>   Bits/Sample: 8
>   Compression Scheme: None
>   Photometric Interpretation: RGB color
>   Orientation: row 0 top, col 0 lhs
>   Samples/Pixel: 3
>   Rows/Strip: 877
>   Min Sample Value: 0
>   Max Sample Value: 255
>   Planar Configuration: single image plane
> scan003.tif:
> TIFF Directory at offset 0x8 (8)
>   Subfile Type: (0 = 0x0)
>   Image Width: 1272 Image Length: 3509
>   Resolution: 75, 75 pixels/inch
>   Bits/Sample: 8
>   Compression Scheme: None
>   Photometric Interpretation: RGB color
>   Orientation: row 0 top, col 0 lhs
>   Samples/Pixel: 3
>   Rows/Strip: 3509
>   Min Sample Value: 0
>   Max Sample Value: 255
>   Planar Configuration: single image plane
>
> -- Jim
>
> On Fri, Mar 10, 2017 at 1:18 PM, Jeff <jf...@po...> wrote:
> > On 09/03/17 04:33, Jim Mayer wrote:
> >> Strangely, I'm pretty sure it's the same driver. The "epkowa" SANE
> >> driver is the one provided by Epson for use with iscan. I think they
> >> either ignore the returned data or are scaling the image. To check
> >> this out, I switched the gscan2pdf front end to "scanimage" and
> >> hand-edited the cached resolution information in $HOME/.gscan2pdf to
> >> include a "150" dpi option. Selecting that option produced a 150dpi
> >> output with the expected size and number of pixels. Unsurprisingly,
> >> though adding a bizarre "126dpi" option scanned and reported the
> >> requested resolution, the number of pixels matched the 150dpi setting.
> >
> > Some backends provide conf files. On my Debian testing system, these are
> > in /etc/sane.d/. If you are lucky, you might be able to affect the
> > options presented by editing the appropriate file.
> >
> > There are other files in /usr/share/sane. On my system, they don't seem
> > to be useful.
> >
> > You might be able to hack the source of the epkowa backend. I had a
> > quick scan through it, but couldn't find where the options are defined.
> >
> >> Also, I thought of another workaround, but you might not like it.
> >> Since the driver reports "150" as valid for the "x-resolution" and
> >> "y-resolution", it would work, at least in this case, to add any value
> >> that showed up in both the "x-resolution" and "y-resolution" lists to
> >> the "resolution" list. The behavior could be controlled by a switch or
> >> an environment variable. I admit that it's kind of gross, and I did
> >> notice that the code is pretty rigorous about not playing with the
> >> values that SANE reports.
> >
> > You're right. I don't like it, as it introduces whole new ways of
> > breaking things, and some SANE backends don't seem very good at dealing
> > with errors.
> >
> > However, in order to do thing properly, I would like to confirm the
> > logic. Please give me the geometry of the images produced by the
> following:
> >
> > scanimage --x-resolution 150 --y-resolution 150 --resolution 75
> >
> > scanimage --y-resolution 300 --resolution 75 --x-resolution 150
> >
> > scanimage --resolution 75 --x-resolution 150 --y-resolution 300
> >
> > Regards
> >
> > Jeff
> >
>