On Wed, Oct 24, 2001 at 10:30:28PM -0300,
[email protected] wrote:
> Hi!
>
> I cannot make sane to scan satisfactorily when resolution is >= 600 dpi in my
> UMAX Astra 2000P.
>
> The image returned is:
>
> - ok at the beginning: let's say the first 200 vertial pixels of the image
> look ok. However, the scan has some 'garbage' at the very beginning (some
> black lines), where the image should not have that number of black lines
>
The few black lines at the beginning are due to a bug in scan area
origin
detection.
> - from that point on (@ vertical pixel 200), the image look somehow
> screwed-up in 'phases'. The anomalities are: color, missing scan lines (parts
> of the original image are not in the resulting scan)
>
> - the resulting scan is, thus, 'smaller' than requested (it has a large white
> portion at the botom)
>
> Looking at xsane output, it seems that the scanner (that's what it seems) is
> not responding fast enough, or that the application (umax_pp_low?) is not
> sending commands as fast as needed by the scanner. All (almost?) the errors
> show up in SendLength() function (umax_pp_low.c), where 'sync is needed' and
> in other cases.
At high dpi, when doing wide scans, the backend has to get enough CPU to
keep on with the bandwidth needed. If not, data chunks are lost, and even if the
backend manage to resync with scanner, picture is garbled. Making sure that no
other
task is eating CPU should improve the scans. You may also narrow the scans. Any
height is OK.
>
> I've tried both with irq enabled and disabled for the port. No changes
> noticed here.
>
> Everything works just fine at 300 dpi.
>
> umax_pp tool scan produces, as you say in sourceforge's pages, a splitted
> scan (switched vertical sides). I don't have a problem with this, as I am
> intending to use sane's backend from xsane frontend.
>
> I don't know if I 'should' be using kernel 2.4.x in order to take advantage
> of ECP (and dma), but I just can't switch to kernel 2.4.x right now (I'm
> waiting for a rcf version that supports iptables and 2.4.x features), so all
> I've got is this 2.2.19 kernel.
>
> I really need to scan at 600x600 and 1200x600 (at least) with my scanner, and
> 300x300 is just not good enough.
>
> Do you have any ideas? I need help with this, please!
>
When the umax_pp uses the 'ppdev' character device instead of direct
I/O,
it relies on the linux parport code wich handles timeouts much better. From my
experiment, the umax_pp works better (altough slower) with it.
>
> I am using:
>
> - umax_pp source patch on sane-1.0.5
> - xsane-0.75-ximian.2
> - linux kernel 2.2.19 (parallel port support built as module)
I think you'll have to patch it to get the 'ppdev character device'.
Recent
2.4 kernels have improved ppdev capabilites which speed up the backend. I think
you should really consider using one.
> - XFree86-4.0.3-5, Ximian GNOME desktop (gnome-core-1.4.0.4-ximian.5)
> - vnc-server-3.3.3r2-14
>
> - Intel Pentium-II @333 MHz, 416 Mb RAM
> - scanner: UMAX Astra 2000P
> - parallel port onboard, 0x378, irq 7, EPP version 1.7 (not ECP, just EPP).
> Everything look right in /proc/parport/0/hardware
> - no other devices attached to the scanner
>
>
[lines deleted]
>
> Thanks and regards,
>
>
> Ezequiel Valenzuela
>
Regards,
Stef
