I use xsane, started from GIMP with a Canon LiDE 220. It works fine at resolutions up to 1200 dpi. When I choose 2400 dpi or 4800 dpi, the following happens: xsane hangs for a while. Sometimes, after a short or long wait (trying to scan an area of 1 cm by 2 cm at 4800 dpi, there was a hang of 20 min before the messagea appeared) , I get an error message "Konnte Scanner nicht starten: Ungültiges Argument" (German for: could not start scanner, invalid argument) or "Konnte Scanner nicht starten: Fehler während Geräte I/O" (German for: could not start scanner, error during device I/O). Afterwards further scans at low resolutions also give the error message. After retsarting xsane, I can scan at resolutions up to 1200 dpi again. According to the manufacturer of the scanne, Canon, the LiDE supports up to 4800 dpi. However, there is a footnote "When scanning in high resolution, the scan size is restricted." in their device description, and Windows users indeed report that he Scanner won't let them scan large areas at full resolution. If this is really a hardware restriction that cannot be worked around it seems sane should: 1) Allow scans of small areas at 2400 and 4800 dpi 2) Immediately give an informative error message when attempting to scan large areas at 2400 or 4800 dpi.
tags 942176 + moreinfo thanks Hello Philipp, please can you check if the bug still exists in the current version? CU Jörg
Am 08.12.20 um 20:24 schrieb Jörg Frings-Fürst: There are still problems at 2400 and 4800 resolutions, but they are different now. The main problem is now about wrong colors at these resolutions. Scans at reolutions up to 1200 still work well as before. I tried to scan a small area (3 cm x 7 cm) at 2400. xsane did hang for about 2 minutes, then scanned, then it took another 3 minutes (for recieving RGB data - the progress bar moving slowly), but then got a good scan result, which looked correct. Similarly when scanning the same area at 4800 (except that it took much longer to reeive the data). But this time the black text appeared bordeux. At a subsequent attempt using a smaller 2.5 cm x 1.5 cm area, the situation was the same, except that the color problem already appeared at 2400. I also tried scanning a large (20 cm x 20 cm) area at 2400 and 4800. There again was the hang at the beginning - about 1 to 2 minutes, but it did scan after that. For both resolutions, the result again had the wrong colors where black appearead as bordeaux. For 4800, I also got a different area than specified. rather than the 20 cm x 20 cm part I selected in xsane (and which I got at 2400), I got an area 20 cm wide and about 0.5 cm high. Summary: The situation improved somewhat, but is still far from perfect: There is still an odd waiting time when starting to scan at 2400 or 4800 (at 1200 and below the scan starts nearly instantly, after less than second). At 4800 colors ar wrong. Once one of these problems appears, it affects all resolutions until restarting xsane: Having done a scan at 2400 or 4800, subsequent scans at lower resolutions also have the waiting time at the start. Having done a scan at 2400 or 4800, where black appeared as bordeaux, subsequent scans at lower resolutions also have wrong colors.
It seems very likely that the original problem is an upstream bug in SANE. There are a few issues reported there specifically against the Canon LiDE 220 that sound very similar: https://gitlab.com/sane-project/backends/-/issues/439 https://gitlab.com/sane-project/backends/-/issues/518 You mentioned that you are using GIMP to launch xsane. The problem with the colors could be occurring there. Can we rule that out? What happens if you run "scanimage" from the command-line — does it produce an image with the correct colors?
Am 17.02.22 um 03:02 schrieb David Ward: These upstream bugs apparently affect all resolutions (they were reported at 300 and 600 dpi). The problem I see only happens above 1200 dpi. Due to a gimp bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994429) I haven't launched xsane from gimp for a while. But your request still helped track down the issue a bit further: I have not been able to reproduce the bug using scanimage from the command line¹ (did various scans at 2400 and 4800 dpi today, using Debian testing). Both speed and color were fine using scanimage from the command line. But I can reproduce the bug using xsane started from the command line (also tested today). I also got a segfault in xsane once (just at the end of a 4800 dpi scan). Philipp ¹ I do get a different bug with scanimage though: For a full-size scan at 4800 dpi, two thirds of the image are just gray.
Does the problem you see from scanimage happen with version 1.1.1 (of libsane1, libsane-common, sane-utils, etc.)?
https://gitlab.com/sane-project/backends/-/merge_requests/374#note_856438189 Cloning this bug in Debian, since there seem to be separate issues in the backend (libsane1) and the graphical frontend (xsane).
Let me clarify that first: The issue in the backend seems to have been reproduced. When trying to use xsane instead of scanimage, one of the developers also got a segfault. Without backtraces, it is not clear if that is related to what you encountered. That also means there wasn't an image produced by xsane, so there was no confirmation about wrong colors. I would assume the upstream priority is fixing the backend first. In any case, still cloning this bug.
Philipp, The 32-bit overflow issue with the backend should be fixed now in libsane1 1.1.1-5. With that installed, can you please try xsane again? Is there still an issue with colors? If you experience segmentation faults, can you please try to obtain a backtrace? https://wiki.debian.org/HowToGetABacktrace Thanks, David