[sane-devel] genesys backend

Pierre Willenbrock pierre at pirsoft.dnsalias.org
Fri Sep 9 17:08:53 UTC 2005


This one should have been sent to the list. I double-checked the From:
field, but didn't realize i just removed the wrong To: field.

(sent on 2005-09-07 to Stéphane VOLTZ <stefdev at modulonet.fr>)

Hi

Stéphane VOLTZ schrieb:
> 	Hello,
> 
> 	it looks genesys_reorder_components_cis_8 and 
> genesys_reorder_components_cis_16 are missing from your patch. 

They do exist. Both are generated from
FUNCNAME(genesys_reorder_components_cis) in genesys_conv_hlp.c.
FUNCNAME(fn) is #defined in genesys_conv.c to be either fn_8 or fn_16.
This is very useful for shrink_lines and reverse_ccd, as those only need
to know the type of the components(u_int8_t or u_int16t), and apart from
that are exactly the same, so the code exists only once, but is included
twice, first with u_int8_t as internally used data type and second with
u_int16_t. The #defines around the #include define which functions will
be generated.

> 	The quick test I did hang at the end of scan (which happens when we try to 
> read more data than the scanning area holds). Is there a test case where a 
> scan succeeds ? I'd like to time how it takes for a scan. Because my main 
> concern is that (as you wrote in a previous mail) data may be copied too 
> much. For the rest, I gone through your code, and it looks sensible to me.

There is still the possibility that i misunderstood the code in
genesys_gl641.c. Could you try to reduce dev->current_setup.lines to
lincnt - 1? dev->current_setup should store the format of the data
coming from the scanner. If the reading process is missing data, one of
the settings is wrong, and reducing the line number should at least
enable you to do one scan, and check that the pixel count is right.

You may have a raw.pnm generated while reading the data. It should be
helpful for determining which settings are bad.
It uses the line count and pixel count from dev->current_setup. To view
the image you probably need to reduce the line count in the file.

Concerning the copying: The data is copied at most 4 times:
(reading)-> data reordering -> line distance/stagger -> line shrink ->
memcpy to destination
That is worse than the current solution, where we have
(reading)-> line shrink -> final reordering etc. into destination

The best case stayed mostly the same:
(reading)-> memcpy to destination
versus
(reading)->final reordering etc. into destination

Adding cis support to the current solution would add a reordering before
line shrink, because of the planar nature of cis data.

> 
> 	What I need is a test case that allow me to compare speed to make up
>  my mind.
> 
> Regards,
> 	Stef
> 

Regards,
  Pierre




More information about the sane-devel mailing list