resolution control: setting x/y resolution independently

[2CV67]

Details in my Ubuntu Forum thread:
http://ubuntuforums.org/showthread.php?t=1648771
Quote:
"Firstly - congratulations for Simple Scan, which lives up to its name admirably!
Xsane is no doubt wonderfully competent, but far too complicated for casual use.
But I am having a problem with Simple Scan, in that I can't seem to get selected resolutions to have any effect.
A typical A4 mainly-text document I am playing with, ends up as:
165K when scanned & saved as text pdf at 75/150/300 or 600dpi...
1.5MB when scanned & saved as text jpg at 75-600dpi
2.2MB when scanned & saved as photo pdf or jpg at 75-600dpi.
My Epson V200 scanner allows normal resolution selection with Xsane or with Epson's iscan application.
Thanks for any suggestions!" - unquote.

I started that thread in December 2010 & still have the same problem today.
As a summary - the resolution control has absolutely no effect on the results.
No error messages (unless I try 2400dpi) & nothing in simple-scan --debug >simple-scan.log
I now have Simple Scan 2.32.0.1-0Ubuntu2 in Ubuntu 11.04.
The scanner is an Epson Perfection V200 Photo & has normal resolution selection in XSane & Iscan.
Thanks!

[Michael Nagel (nailor)]

I am not sure if the scan resolution does have so much effect on file size with text-only documents. (It should have some effect, though.) Can you try to scan a colorful photo where the change in file size should be more dramatic to confirm that it is not the problem?

[2CV67 (2cv67)]

Thanks for your interest!

I scanned a printed postcard (not normal pc format though) using the following procedure:
Open Simple Scan.
Document > Preferences > Text Resolution > 75dpi > Photo Resolution > 75dpi > Close > Scan (Photo) > Crop > Save.
Document > Preferences > Text Resolution > 150dpi > Photo Resolution > 150dpi > Close > Scan > Save. (Same cropped size)
Document > Preferences > Text Resolution > 300dpi > Photo Resolution > 300dpi > Close > Scan > Save.
Document > Preferences > Text Resolution > 600dpi > Photo Resolution > 600dpi > Close > Scan > Save.
Document > Preferences > Text Resolution > 1200dpi > Photo Resolution > 1200dpi > Close > Scan > Save.
Document > Preferences > Text Resolution > 2400dpi > Photo Resolution > 2400dpi > Close > Scan > Save.
Document > Preferences > Text Resolution > 75dpi > Photo Resolution > 75dpi > Close > Scan > Save.

Results:
Image sizes:
75dpi - 911.9KB
150dpi - 915.2KB
300dpi - 917.9KB
600dpi - 919.0KB
1200dpi - 919.7KB
75dpi#2 - 920.3KB
All images are identical at any degree of zoom (tried up to 14x)
The 2400dpi test failed with error message "Failed to scan - Unable to start scan".

I ran a similar test with Epson's iscan application.
Results:
Image sizes:
72dpi - 24.4KB
150dpi - 128.9KB
300dpi - 878.1KB
600dpi - 3.3MB
1200dpi - 10.3MB
2400dpi - failed "Selected area too large for this resolution"
All these images are very different at any zoom factor.

The Simple Scan images are visually somewhere between the iscan 150 & 300 images at 14x zoom, nearer the 300.
Probably the jpeg settings are different.

All images available for any further investigations & don't hesitate to ask for any further tests.

Thanks!

[DemoFreak (demofreak-9)]

Same problem here:

Canon CanoScan 9000F
sane-backends 1.0.23
simple-scan 3.2.1/3.4.0

- scanning a document in several resolutions (300, 600, 1200dpi) results in output files of same size, all seems to be scanned at 600dpi
- scanner noise sounds equal (while normally sounds "faster" at 300dpi and much "slowlier" at 1200dpi)
- when saved as PDF, only the 600dpi scan has the correct screen size at 100% scale
- "crop to A4 size" from menu only works correct at 600dpi, when scanning at other resolutions the cropped area is too small/too big

Scanning with xsane and skanlite works correct on all resolutions, so it seems to be a simple-scan problem.

How can I help to narrow down the issue? I'm willing to make an reasonable effort to this (within the borders of my knowledge ;-), as simple-scan is a very helpful tool in daily usage (like document archiving).

TIA,

/Hannes

[DemoFreak (demofreak-9)]

...as discussed in IRC

[DemoFreak (demofreak-9)]

Logs of 3 scans with different resolutions (300/600/1200dpi)...

[Michael Nagel (nailor)]

for future reference IRC log:

(09:08:04) Michael Nagel: hi DemoFreak
(09:08:37) robert_ancell: DemoFreak, welcome
(09:08:43) Michael Nagel: i suggest you (DemoFreak) mention your topic now
(09:09:19) DemoFreak: ok, i think it's shorter if i post the url ;)
(09:09:22) DemoFreak: https://bugs.launchpad.net/simple-scan/+bug/891586/comments/3
(09:09:41) DemoFreak: i'd like to know how i could help to solve this issue
(09:10:22) DemoFreak: i'm no coder, but an rather experienced linux user
(09:10:32) robert_ancell: DemoFreak, great! The first thing to do is look at the log in ~/.cache/simple-scan - this will tell you all the information that simple-scan got from the scanner
(09:10:51) DemoFreak: so my help would be limited to tests and log-generating ;)
(09:11:04) DemoFreak: ok
(09:11:23) DemoFreak: shall i attach that to this bug?
(09:12:12) robert_ancell: yes please
(09:13:05) robert_ancell: Simple Scan does it's best to match the resolution chosen by the user, but I'm wondering if your scanner is confusing it
(09:13:52) DemoFreak: formerly i own an hp5370c, there was no problem at all (i think)
(09:14:25) robert_ancell: Note that simple-scan --debug is broken (due to a change in glib) so I need to fix it. But it is the same content as in ~/.cache
(09:14:57) robert_ancell: DemoFreak, are you able to get the log now, then we can have a quick look at it
(09:14:57) DemoFreak: the canon sane backend is rather new, maybe it's a combo out of this quite untested backend and simple-scan
(09:15:02) DemoFreak: mom
(09:15:19) DemoFreak: i have a ~500kb log there
(09:15:36) robert_ancell: it's a quite detailed log :)
(09:15:47) DemoFreak: shall i generate a new log, or will you read through 500kb? ;)
(09:16:01) DemoFreak: ok, will attach now
(09:17:55) DemoFreak: robert_ancell: https://bugs.launchpad.net/simple-scan/+bug/891586/comments/4
(09:20:12) robert_ancell: DemoFreak, thanks. So the log says your scanner claims to do 75, 150, 300, 600, 1200, 2400, 4800 resolutions
(09:20:26) DemoFreak: yes
(09:20:45) DemoFreak: i tried 300, 600 and 1200
(09:21:37) robert_ancell: I'll have to have another look later, but the log looks ok for now
(09:22:25) Michael Nagel: hmmm :( let's postpone this
(09:22:26) DemoFreak: maybe i'm AFK later, but i'll read the backlog
(09:46:43) DemoFreak: sorry for disturbing again ;-): i've generated 3 single logs with different resolution scans for better comparison. shall i upload the tarball as attachment to the bug?
(09:46:50) robert_ancell: DemoFreak, yes please
(09:47:05) DemoFreak: ok. i'm out for now. cya ;)

[2CV67 (2cv67)]

Hi! I am the original reporter of this bug.
Happy to see there is some new activity.

If my log files can be any use, please indicate what manipulations would be interesting.
(& please indicate how best to compress/attach/send them if critical).
I currently have one 194KB simple-scan log file - it seems only the latest session is retained?

The original images (mentioned in earlier posts) are no longer available, but I can easily repeat similar tests.

Thanks for continuing investigations!

[Michael Nagel (nailor)]

attach the logs as a file to the report. either compressed or uncompressed (i even prefer uncompressed, because i can view it directly in the browser and bandwidth is not an issue for me, but other might disagree). as long as the size is not mega/gigabytes there is no problem with that.

just scan one page with two or three different resolutions.

[2CV67 (2cv67)]

OK - I scanned a complete page (about A4 uncropped) as Photo & saved in jpg format, at 75/150/600dpi.

All 3 came out identical at 2.7MB & 2544x3509px.

I notice the log file refers to the same weird X & Y dpi values that I see in XSane (X=75/300/600/1200/2400etc & Y=100/200/300/400/600etc)

Logfile hopefully attached...

[Michael Nagel (nailor)]

i remember that i heard there are scanners that have different x and y resolutions. maybe this confuses simple-scan.
however i do not see anything about separate x/y res in DemoFreak's logs.

[2CV67 (2cv67)]

Epson's own driver (Image Scan! for Linux 2.28.1) currently offers me 50/72/96/150/200/240/300/360/400/600/720/800/1200/1600/2400/3200/4800/6400/9600dpi for this scanner - without distinguishing between X & Y.

http://ubuntuforums.org/showthread.php?t=1577867

[Michael Nagel (nailor)]

2cv67 can you run:
scanimage --help
to confirm the list of resolutions the backend reports? I suspect something is broken there and you should take this to sane-devel.

DemoFreak: could you also provide the list of resolutions given by scanimage --help and the list of resolutions your scanner supports according to the manufacturer?

[2CV67 (2cv67)]

Scanimage --help attached.

[Michael Nagel (nailor)]

2CV67 Epson Perfection V200 iscan
50/72/96/150/200/240/300/360/400/600/720/800/1200/1600/2400/3200/4800/6400/9600dpi for this scanner - without distinguishing between X & Y.

2CV67 Epson Perfection V200 scanimage
    --resolution 300|2400|4800dpi [300]
        Sets the resolution of the scanned image.
    --x-resolution 75|300|600|1200|2400|4800dpi [300]
        Sets the horizontal resolution of the scanned image.
    --y-resolution 100|200|300|400|600|800|1200|1800|2400|3600|4800|6600|9600dpi [300]

2CV67 Epson Perfection V200 simple-scan
[+111.47s] DEBUG: scanner.vala:816: sane_get_option_descriptor (12)
[+111.47s] DEBUG: scanner.vala:666: Option 12: name='resolution' title='Scan resolution' type=int size=4 unit=dpi values=[300, 2400, 4800] cap=,soft-select,soft-detect
[+111.47s] DEBUG: scanner.vala:669: Description: Sets the resolution of the scanned image.
[+111.47s] DEBUG: scanner.vala:423: sane_control_option (12, SANE_ACTION_SET_VALUE, 150) -> (SANE_STATUS_GOOD, 300)
[+111.47s] DEBUG: scanner.vala:816: sane_get_option_descriptor (13)
[+111.47s] DEBUG: scanner.vala:666: Option 13: name='x-resolution' title='X-resolution' type=int size=4 unit=dpi values=[75, 300, 600, 1200, 2400, 4800] cap=,soft-select,soft-detect,advanced
[+111.47s] DEBUG: scanner.vala:669: Description: Sets the horizontal resolution of the scanned image.
[+111.47s] DEBUG: scanner.vala:816: sane_get_option_descriptor (14)
[+111.47s] DEBUG: scanner.vala:666: Option 14: name='y-resolution' title='Y-resolution' type=int size=4 unit=dpi values=[100, 200, 300, 400, 600, 800, 1200, 1800, 2400, 3600, 4800, 6600, 9600] cap=,soft-select,soft-detect,advanced
[+111.47s] DEBUG: scanner.vala:669: Description: Sets the vertical resolution of the scanned image.

Begin Theory
Simple Scan lets the user select a resolution, but imho it does not display the list of supported resolutions in the GUI but only some sensible values. After the user made his choice, the best actually supported resolution is chosen.

I have the feeling somehow only 300 2400 4800 is considered in your case and if you do scans with 75dpi 150dpi 300dpi 600dpi 1200dpi you always end up with doing scans with 300 dpi because those resolutions with split x/y are not considered...
End Theory

Is my theory consistent with your experiments, 2cv67?
Is my theory consistent with the code, Robert?

[2CV67 (2cv67)]

"Is my theory consistent with your experiments, 2cv67?"

Probably, yes.

If I select 75/150/300/600/1200dpi then I get an identical result which is probably 300dpi.

If I select 2400dpi then I get an error message "Failed to scan. Unable to start scan".
Presumably a memory limit somewhere?
No amount of cropping will change that - I suppose Simple Scan does it's cropping after scanning?

Back in Epson's iScan, then if I try to scan a complete uncropped scanner bed (like in Simple Scan) at 2400dpi then I also get an error message "Selected area is too large for this resolution. Reduce the selected area or resolution"
Because iScan works with a pre-scan > crop > scan method, then I can reduce the area to get a successful scan at 2400dpi, but it is less than 1/4 of the scanner bed size.
I didn't find the exact limit, but it was successful at 7480x10123px (11.1MB).

So yes - your theory seems to fit.

Congratulations for that!

[2CV67 (2cv67)]

"importance: Undecided → Low "

I suppose that means nothing will happen in the Simple Scan world.

Can somebody familiar with the rest of the scanner universe suggest where I should try my luck next?
I think you mentioned sane-devel?
Could you be more precise?
What should be my complaint/request?
Thanks for that & thanks for your effort to date!

[DemoFreak (demofreak-9)]

As requested by Michael Nagel:

Supported resolutions as stated by Canon Scangear (Win XP):
50, 75, 100, 150, 200, 300, 400, 600, 800, 1200 dpi for flat bed
300, 400, 600, 800, 1200, 1600, 2400, 3200, 4800, 6400, 9600 for transparency unit

Resolutions detected by scanimage see attachment.

/Hannes

[Michael Nagel (nailor)]

guys, you convinced me and I raise priority to medium.
i was setting priorities according to my personal, possibly inaccurate, "how bad do I feel shipping a program with this problem"-rule.

however, please remember, that nobody is paid to work through the lists from top to bottom.
the best way to get a problem fixed is to actively collaborate, and do things yourself and/or answer questions quickly and precisely. in this regard i am positive that this a bug report where a solution will be found.

for one, we have to wait for Robert to comment.
additionally you might try to acquire a scan at a different resolution via scanimage. if this works, we should make simple-scan do it the same way, if it does not, you should contact the backend developers via the sane-devel mailing list.

DemoFreak, could you paste for future reference a list of supported resolutions as listed by the manufacturer/simple-scan/scanimage simliar to the list form 2cv67?

[DemoFreak (demofreak-9)]

As I figured out just now, the sane tools behave different regarding the resolution:

- xsane respects the selected resolution (tested with 300, 600 and 1200dpi). The output files differs in size by factor 4, as expected.

-rw-r----- 1 hannes users 25658079 14. Apr 19:36 test0001.pnm
-rw-r----- 1 hannes users 102666906 14. Apr 19:37 test0002.pnm
-rw-r----- 1 hannes users 410624709 14. Apr 19:38 test0003.pnm

- scanimage always scans with 600dpi (like simple-scan does), regardless what's given by --resolution parameter. The output files are similar in size.

hannes@gurkenkiste:~> scanimage -d pixma:04A91908 --resolution 300 --mode Color --source Flatbed >test1
hannes@gurkenkiste:~> scanimage -d pixma:04A91908 --resolution 600 --mode Color --source Flatbed >test2
hannes@gurkenkiste:~> scanimage -d pixma:04A91908 --resolution 1200 --mode Color --source Flatbed >test3

-rw-r--r-- 1 hannes users 107429029 14. Apr 19:51 test1
-rw-r--r-- 1 hannes users 107429029 14. Apr 19:51 test2
-rw-r--r-- 1 hannes users 107429029 14. Apr 19:51 test3

So it seems the problem is located in an interaction of the scan frontend and the sane backend (as scanimage/simple-scan are able to scan with the configured resolution when using other devices, and on the other hand xsane is able to scan the desired resolution with _this_ specific device).

Any hint to narrow down this issue a little further?

/Hannes

[2CV67 (2cv67)]

"additionally you might try to acquire a scan at a different resolution via scanimage"

Sorry to be so slow responding, but I am allergic to terminal & so Scanimage has been a difficult experience...

I did eventually get scanimage to produce its default image, using:
"chris@Acer-desk:~$ scanimage >scan-file.pnm"
This image was 26MB - the same size as iScan / 300dpi / color document / .pnm.

Much later, after many failed attempts, I think I discovered the right command for 150dpi, with this result, showing that scanimage uses the nearest "default" resolution:
"chris@Acer-desk:~$ scanimage --r 150 >scan-file2.pnm
scanimage: rounded value of resolution from 150 to 300"

That produced another 26MB image, but terminal never came back to a prompt.
When I tried to close terminal, I got a warning that a process was still running & I had to kill it to exit, which I did.
After that, the scanner could not be stopped on the button until the next reboot & no scanning was possible with any program as the scanner was "busy" or whatever.

Now, even after cold reboots & even after only a basic "$ scanimage >scan-file.pnm" scanimage never gets back to a terminla prompt & I have to kill process to exit terminal every time!

Next, I went to see how it worked in Ubuntu 10.04LTS which multiboots on the same PC & Scanner & where I have never tried scanimage.
I simply tried "$ scanimage >scan-file.pnm" which produced a 25MB image as expected but, surprisingly for me, failed to return to a prompt & forced me to kill process to exit terminal...
This sounds as though I have now screwed up something inside the scanner, doesn't it?

Fortunately, iScan & Simple Scan & XSane seem unaffected as long as I don't use scanimage.

So I suppose I try sane-devel now...

[Michael Nagel (nailor)]

can you try:

scanimage --x-resolution 600 --y-resolution 600 > si-600-600.pnm
scanimage --x-resolution 600 > si-600--.pnm
scanimage --y-resolution 600 > si---600.pnm

[Michael Nagel (nailor)]

from grepping through the sources i am quite confident that simple-scan uses "--resolution" exclusively and ignores "--x-resolution" and "--y-resolution"

so if above commands work, we have the explanation.

ps: possibly you need:

--resolution-bind=no as in

scanimage --resolution-bind=no --x-resolution 600 --y-resolution 600 > si-600-600.pnm
scanimage --resolution-bind=no --x-resolution 600 > si-600--.pnm
scanimage --resolution-bind=no --y-resolution 600 > si---600.pnm

[DemoFreak (demofreak-9)]

Hm, what a pity ;)
I hoped, that this x/y-resolution-thingy would be the solution, maybe... but my sane-backend don't even know this parameters. So it has to be something else...
In fact, scanimage (and therefore simple-scan, ) don't respect the --resolution parameter, but xsane does.

[2CV67 (2cv67)]

"can you try: scanimage --x-resolution 600 --y-resolution 600 > si-600-600.pnm etc"

Assuming that was for me, I tried it & added something.
Terminal transcript here & my comments below.

Terminal:

chris@Acer-desk:~$ scanimage --x-resolution 600 --y-resolution 600 > si-600-600.pnm
chris@Acer-desk:~$ scanimage --x-resolution 600 > si-600--.pnm
chris@Acer-desk:~$ scanimage --y-resolution 600 > si---600.pnm
chris@Acer-desk:~$ scanimage --resolution-bind=no --x-resolution 600 --y-resolution 600 > sinb-600-600.pnm
scanimage: unrecognized option '--resolution-bind=no'
chris@Acer-desk:~$ scanimage --x-resolution 150 --y-resolution 150 > si-150-150.pnm
scanimage: rounded value of x-resolution from 150 to 75
scanimage: rounded value of y-resolution from 150 to 100
chris@Acer-desk:~$ scanimage --x-resolution 600 --y-resolution 600 > si-600-600-2.pnm
chris@Acer-desk:~$

Comments:
Tests #1 & #2 & #3 produced results with size & shape consistent with 600dpi where specified & 300dpi elsewhere (107MB / 54MB / 54MB).
Interestingly, no terminal freezing with #1 & #2 but froze after #3.
In fact I see now that terminal does not permanently freeze - but it takes 3 minutes to get back to prompt!
No output with --resolution-bind=no.

I tried #5 with 150-150 which produced the message about rounded values and a result which was 75-100 (2.2MB).
#5 again caused terminal "freeze" which unfroze after 3 minutes...
#6 was just to recheck #1 & was OK with no freeze.

I am out of my depth here, but you seem to be on to something!

Thanks!

[DemoFreak (demofreak-9)]

Rolf Bensch from Sane devel mailing list worked out, that the parameter order is important to scanimage.

dont work: scanimage --resolution 300 --source Flatbed
works: scanimage --source Flatbed --resolution 300

So maybe simple-scan uses scanimage with the "dont work" parameter order as well?

/Hannes

[Michael Nagel (nailor)]

The 3 minute freeze: http://lists.alioth.debian.org/pipermail/sane-devel/2012-February/029481.html

The thing is that SANE provides two ways to set the resolution:

A: "resolution" set to some value
B: "x-resolution" and "y-resolution" are set to some value

Simple Scan supports only method A.
xsane and scanimage support A and B.

Ususally this is not a problem, but the values for A are very limited with your scanner, see the next list.

2CV67 Epson Perfection V200 scanimage
    --resolution 300|2400|4800dpi [300]
        Sets the resolution of the scanned image.
    --x-resolution 75|300|600|1200|2400|4800dpi [300]
        Sets the horizontal resolution of the scanned image.
    --y-resolution 100|200|300|400|600|800|1200|1800|2400|3600|4800|6600|9600dpi [300]

Additionally, the list of resolutions displayed in Simple Scan is not the list of resolutions supported by the hardware. The list is static, and you can select whatever you want. When scanning the next available resolution is chosen. In your case the choice is limited to 300/2400/4800 as Simple Scan only supports only method A.

From my point of view there are two things to do:
1) Simple Scan should support method A.
2) Someone with knowledge of the backend/driver should check if these lists are correct, especially if the list for method A is really that short.

[Michael Nagel (nailor)]

1) Simple Scan should support method A.
should read
1) Simple Scan should additionally support method B.

[Michael Nagel (nailor)]

DemoFreak: as it is becoming more and more clear that your problem is separate from the problem discussed initially, may I ask you to open another ticket and just copy the findings thus far? I think this will simplify the discussion... Thanks!

[2CV67 (2cv67)]

Thank you so much, Michael Nagel, for your hard work here & on the sane-devel list!

I feel very dumb about sending my post there in html...

I found the thread about 3-minute freeze this afternoon, but am not understanding much.

[DemoFreak (demofreak-9)]

Splitting issue:

simple-scan disregards resolution selection probably due to wrong parameter order:
https://bugs.launchpad.net/simple-scan/+bug/983441

/Hannes

[Michael Nagel (nailor)]

> The thing is that SANE provides two ways to set the resolution:
> >
> > A: "resolution" set to some value
> > B: "x-resolution" and "y-resolution" are set to some value
> >
> > Simple Scan supports only method A.
> > xsane and scanimage support A and B.
> >
> > Ususally this is not a problem, but the values for A are very limited
> > with your scanner, see the next list.
That is to be expected as it is the intersection of the x-resolution and
y-resolution lists.

> Additionally, the list of resolutions displayed in Simple Scan is not
> > the list of resolutions supported by the hardware. The list is static,
> > and you can select whatever you want. When scanning the next available
> > resolution is chosen. In your case the choice is limited to
> > 300/2400/4800 as Simple Scan only supports only method A.
> >
> >>From my point of view there are two things to do:
> > 1) Simple Scan should support method B.
Indeed it should. As a matter of fact, the SANE API doesn't even
guarantee that you can use method A :-) See section 4.5.2 of the
specification for details.

As a third and complementary approach, Simple Scan can scale the image
to the resolution that the user selected. Image Scan! for Linux does
that. Right now, Simple Scan gives the user the false impression that a
certain resolution is used to get and create an image. All it really
does is let the user select a lower bound on the resolution. And it
does that without clearly saying so. The user will expect an image with
the UI selected resolution (no matter what was used to get it). If the
selected resolution is wildly different (and smaller) than that used to
acquire the image, users may get impatient because it takes such a long
time but that's another issue.

Hope this helps,
-- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962

[Michael Nagel (nailor)]

2CV67, can you please check if release 3.4.1 changes anything for you? it fixes Bug #983441

Robert, can you comment on setting x/y resolution independantly? according to Olaf, who should be considered knowledgeable, completely ignoring it might be playing with fire...

[2CV67 (2cv67)]

"2CV67, can you please check if release 3.4.1 changes anything for you?
it fixes Bug #983441"

I will try, but may need a little guidance...

I uninstalled 3.2.1 with Synapt.
I found & downloaded 3.4.1.
I extracted the tar.gz, opened the "simple-scan-3.4.1." folder & am reading "INSTALL".

Presumably I need to follow some or all of the 8 steps after "The simplest way to compile this package is: " ?

[Michael Nagel (nailor)]

what version of ubuntu are you running? are you running ubuntu?

[2CV67 (2cv67)]

I am mainly using Lubuntu 11.10 but also have Ubuntu 10.04LTS installed.
So far, here, I am talking about 11.10.

[Robert Ancell (robert-ancell)]

2CV67, run the following commands
$ tar xf simple-scan-3.4.1.tar.gz
$ cd simple-scan-3.4.1
$ sudo apt-get build-dep simple-scan
$ ./autogen.sh --prefix=`pwd`/install
$ make
$ make install
$ ./src/simple-scan

[Robert Ancell (robert-ancell)]

I'm not opposed to a patch getting simple-scan to use "x-resolution" and "y-resolution" if "resolution" does not exist or does not contain the requested resolution (though that seems like it should be considered a driver bug).

[2CV67 (2cv67)]

"2CV67, run the following commands
$ tar xf simple-scan-3.4.1.tar.gz
$ cd simple-scan-3.4.1
$ sudo apt-get build-dep simple-scan
$ ./autogen.sh --prefix=`pwd`/install
$ make
$ make install
$ ./src/simple-scan"

Thanks for the detailed instructions (exactly what I need) - but that failed with:
"Checking for required M4 macros...
  yelp.m4 not found
***Error***: some autoconf macros required to build simple_scan
  were not found in your aclocal path, or some forbidden
  macros were found. Perhaps you need to adjust your
  ACLOCAL_FLAGS?

chris@Acer-desk:~/Downloads/simple-scan-3.4.1$ make
make: *** No targets specified and no makefile found. Stop.
chris@Acer-desk:~/Downloads/simple-scan-3.4.1$ "

Full terminal dump attached.

Next?

[Michael Nagel (nailor)]

Robert Ancell wrote:
I'm not opposed to a patch getting simple-scan to use "x-resolution" and "y-resolution" if "resolution" does not exist or does not contain the requested resolution (though that seems like it should be considered a driver bug).

I do not think it has to be considered a driver bug.

As Olaf writes:
Indeed [Simple Scan] should [support independent x/y resolution]. As a matter of fact, the SANE API doesn't even
guarantee that you can use [the same resolution for x/y] :-) See section 4.5.2 of the [SANE] specification for details.

In practice most scanners do support at least some resolution with identical x/y resolution, but it should not be taken for granted and the independent solution should not be some feature request but considered part of using the API properly.

It does not need to be fixed immediatly (because obviously it works without a lot of times), but we should keep an eye on it...

[Robert Ancell (robert-ancell)]

2CV67, try installing yelp-tools:
$ sudo apt-get install yelp-tools

[Robert Ancell (robert-ancell)]

The driver bug I'm referring to is:

2CV67 Epson Perfection V200 scanimage
    --resolution 300|2400|4800dpi [300]
        Sets the resolution of the scanned image.
    --x-resolution 75|300|600|1200|2400|4800dpi [300]
        Sets the horizontal resolution of the scanned image.
    --y-resolution 100|200|300|400|600|800|1200|1800|2400|3600|4800|6600|9600dpi [300]
        Sets the vertical resolution of the scanned image.

I'd expect --resolution to be able to take 300|600|1200|2400|4800 if it is a shortcut for setting the x and y resolution independently.

So the logic simple scan should take is:
1. Use --resolution if it exists and has a value we require
2. Use --x-resolution, --y-resolution if they exist and contain the values we require
3. Do the closest match using 1 or 2
4. Do not set resolution

[Michael Nagel (nailor)]

I already asked this on sane-devel. Olaf's response:

> > If 2CV67's numbers are correct that answer is not completly correct.
> >
> > Epson Perfection V200 scanimage
> > --resolution 300|2400|4800dpi [300]
> > Sets the resolution of the scanned image.
> > --x-resolution 75|300|600|1200|2400|4800dpi [300]
> > Sets the horizontal resolution of the scanned image.
> > --y-resolution 100|200|300|400|600|800|1200|1800|2400|3600|4800|6600|9600dpi [300]
> >
> > The intersection would be 300|600|1200|2400|4800 but 600 and 1200 are
> > missing from the list generated by scanimage.
Good catch. My explanation was not quite complete.

If you try the help with --source="Transparency Unit", you should see
slightly different lists of --x-resolution and y-resolution values. The
list of --resolution values is the intersection of these lists and those
above.

Hope this helps,
Olaf Meeuwissen

[2CV67 (2cv67)]

"2CV67, try installing yelp-tools:"

I installed yelp-tools using Synapt (GUI wherever possible...)

Where should I pick up the previous instructions now, please?

[2CV67 (2cv67)]

"If you try the help with --source="Transparency Unit", you should see
slightly different lists of --x-resolution and y-resolution values."

Yes - attached.

[Michael Nagel (nailor)]

Snippet from logs
    --resolution 300|2400|4800dpi [300]
        Sets the resolution of the scanned image.
    --x-resolution 300|2400|4800dpi [300]
        Sets the horizontal resolution of the scanned image.
    --y-resolution 100|300|600|1200|1800|2400|3600|4800|6600|9600dpi [300]
        Sets the vertical resolution of the scanned image.

2cv67
you can delete the simple-scan-3.4.1 folder and do just redo the steps from #36

[2CV67 (2cv67)]

"2cv67 - you can delete the simple-scan-3.4.1 folder and do just redo the steps from #36"

I can do anything if given precise-enough instructions...

Note (above) that I have started to install 3.4.1. & stalled somewhere, then installed yelp-tools.

So I don't know exactly what I have got & where.

So I need to know exactly what to remove from where, etc.

Thanks for your understanding!

[2CV67 (2cv67)]

Oh - OK!

Yes - I will do that.

Sorry

[2CV67 (2cv67)]

"2cv67 - you can delete the simple-scan-3.4.1 folder and do just redo the steps from #36"

Failed at "make" - see attached.

[2CV67 (2cv67)]

Do I just give up on 3.4.1. then?

By the way - was I right to remove 3.2.1. before trying to install 3.4.1. ?

[Michael Nagel (nailor)]

> By the way - was I right to remove 3.2.1. before trying to install 3.4.1. ?
yes

> Do I just give up on 3.4.1. then?
Let's wait for some feedback from Robert.

[2CV67 (2cv67)]

"> Do I just give up on 3.4.1. then?
Let's wait for some feedback from Robert. "

......?

[Robert Ancell (robert-ancell)]

So what I think Simple Scan should do:
- It can only support images with the same x/y resolutions
- It should support setting x-resolution and y-resolution if the resolution setting does not contain the requested value
- If it still can't get the required resolution (e.g. 600dpi in comment #45) then it should support setting a higher resolution in one dimension and decimating the values (e.g. x-resolution=2400dpi, y-resolution=600dpi, only use every 4 x values).

[Michael Nagel (nailor)]

(19:33:33) Michael Nagel: -- resolution control: setting x/y resolution independently https://bugs.launchpad.net/simple-scan/+bug/891586
(19:34:36) Michael Nagel: this has two aspects: it is quite hard to get a current simple-scan on older ubuntu releases, as the dependencies are tricky
(19:34:55) robert_ancell: yes
(19:35:37) Michael Nagel: do you know if it is possible simple scan 3.4.1 on ubuntu 11.10 as discussed there?
(19:35:39) robert_ancell: that falls into the "too bad" basket to some degree
(19:36:03) robert_ancell: I don't have time to support older platforms, but others are welcome to do
(19:36:52) Michael Nagel: and the second aspect is: scanners do not always offer the same resolutions in x/y direction and sane does not abstract that away either.
(19:37:31) robert_ancell: I don't really want to support different x and y resolutions, that kind of breaks the "simple" part of simple scan
(19:38:16) robert_ancell: the case that some drivers support x-res=z and y-res=z and not res=z seems like a driver problem. We should handle falling back to setting x-res and y-res as sane doesn't require res to exist
(19:38:42) Michael Nagel: i agree. but it leaves one with very few resolutions in some cases and even no cases in theory.
(19:39:01) robert_ancell: but I wonder what type of hardware they have - is it common?
(19:39:32) Michael Nagel: i think it is a scanner with two scanning units
(19:39:37) Michael Nagel: a normal for paper
(19:40:06) robert_ancell: in the comment #45, they do have enough resolutions, but they have the driver bug I described above
(19:40:07) Michael Nagel: and one for (i dont know the proper english word) dias/transparencies
(19:40:19) robert_ancell: transparencies sounds correct
(19:40:39) Michael Nagel: like old-school photos to be projected to a wall
(19:41:12) robert_ancell: correction - comennt 41 has the bug, comment 45 is a driver with very limited options
(19:42:01) robert_ancell: so we could support that - if we decimate some of the values (i.e. scan at x=2400, y=600 and use every fourth x value)
(19:42:15) robert_ancell: it would be kind of nice if the driver did it for us
(19:42:45) robert_ancell: as long as the final image has the same res in both directions I'm ok with it
(19:43:23) Michael Nagel: --resolution seems to more "clever" (dumb in this case) than just setting x and y
(19:43:57) Michael Nagel: as it checks the other scanning modes as well and discards resolutions not supported by all modes
(19:44:12) robert_ancell: so i'd keep the bug triaged, there is a solution for drivers like this. it will take some work.
(19:44:24) robert_ancell: I'll update the bug now
(19:44:26) Michael Nagel: modes meaning "normal unit" and "transparency unit"
(19:45:09) Michael Nagel: --x-resolution seems to list the resolutions for the current mode and that might be a superset.
(19:45:51) Michael Nagel: you can intersect --x-resolution and --y-resolution manually and that set both instead of using --resolution
(19:46:04) Michael Nagel: at least thats how i understand the issue