[sane-devel] genesys backend

[Stéphane VOLTZ]

Le Lundi 29 Août 2005 20:01, Pierre Willenbrock a écrit :
> Hi
>
> 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"
> data.
>       
        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
first.

> 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

        ...O.....O.....O.....O.....O.....O.....O
        ..O.O...O.O...O.O...O.O...O.O...O.O...O.
        .O...O.O...O.O...O.O...O.O...O.O...O.O..
        O.....O.....O.....O.....O.....O.....O...



> 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,
> unshrinked)
>   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.
>
> Regards,
>   Pierre

        I'll test and check in your patch Wednesday morning.

Regards,
        Stef