Philipp,
On 2/21/2022 5:01 AM, Philipp Klaus Krause wrote:
On 12/9/2020 8:22 AM, Philipp Klaus Krause wrote:
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.
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?
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.
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
