[sane-devel] genesys backend
stefdev at modulonet.fr
Mon Aug 29 20:22:07 UTC 2005
Le Lundi 29 Août 2005 20:01, Pierre Willenbrock a écrit :
> As promised
> Pierre Willenbrock schrieb:
> > Next i will implement the slope table generation in the way Stéphane
> > suggested.
> i am sending the result of this work. I introduced a new flag
> GENESYS_FLAG_ALT_SLOPE_CREATE to indicate that the alternate slope
> creation functions should be used.
> Apart from that the patch contains my version of
> sanei_genesys_exposure_time(called sanei_genesys_exposure_time2 to not
> collide with uses of the other function) and a few bug fixes:
> * size argument of sanei_genesys_create_gamma_table changed from float
> to int
> * sanei_genesys_read_reg_from_set and sanei_genesys_set_reg_from_set
> check for address of current register. If this is 0 they should stop.
> * fixed raw data dumping: should write first set of data and close file
> * moved call to sanei_genesys_init_structs to before init_options as
> init_options depends on an initialized device struct.
> Next i'd like to rewrite genesys_read_ordered_data to be more
> maintainable and able to convert the cis style planar data to "chunky"
It is indeed a rather complicated function. Data doesn't come in an
easy form. But I don't exactly see why you want to convert to planar data
> For that i need to know what the "stagger" effect exactly is. I am not
> sure i got that one right.
At high motor resolution, lines are staggered, ie they aren't
horizontal lines. On pixel is on a line, the folowing colunm is on another ...
A drawing may be more evident:
'O' are pixel of on horizontal line, '.' other lines data
> The conversion stack i have in mind looks like this:
> 1. (opt)uncis (assumes color components to be laid out planar)
> 2. (opt)unstagger (assumes pixels to be depth*channels/8 bytes,
> 3. (opt)shrink_lines (assumes pixels to be depth*channels/8 bytes)
> 4. (opt)reverse_RGB (assumes pixels to be BGR or BBGGRR))
> here we should save the finished lines for use with line distance
> correction 5. (opt)line_distance_correction (assumes RGB or RRGGBB)
> My implementation currently used for Canon LiDE 35 does quite a lot byte
> moving which considerably slows down the conversion, and is probably not
> correct regarding the stagger effect.
I'll test and check in your patch Wednesday morning.
More information about the sane-devel