[sane-devel] sane: umax_pp driver - problems scanning at 600 dpi

[stef]

On Wed, Oct 24, 2001 at 10:30:28PM -0300, eze_panda_mostang_sane_devel@ezel.mailshell.com 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