[sane-devel] (no subject)

[Pierre Willenbrock]

Guillaume Gastebois schrieb:
> Hello,
> 
> Is there a possibility to determine a maximum of parameter like :
> 
> typedef struct
> {
>   int optical_res;             (OK, for me 2400)
>   int black_pixels;            (don't know how to determine)
>   int dummy_pixel;             (content of 0x34 ?)
>   int CCD_start_xoffset;       (test of page upper border ?)
The ccd line first gives a few dummy pixels, then there are a few black 
pixels, to enable the afe to do per-line black level compensation. 
CCD_start_xoffset counts into one of these. I didn't need to change 
these, yet.

>   int sensor_pixels;	       (just 216/2.54*2400 ?)
i would think so.

>   int fau_gain_white_ref;      (don't know how to determine)
>   int gain_white_ref;	       (don't know how to determine)
the two above are used in calibration of some gl646-models.

>   u_int8_t regs_0x08_0x0b[4];  (OK windows snoop)
>   u_int8_t regs_0x10_0x1d[14]; (OK windows snoop)
>   u_int8_t regs_0x52_0x5e[13]; (OK windows snoop)
>   float red_gamma;             (don't know how to determine)
>   float green_gamma;           (don't know how to determine)
>   float blue_gamma;            (don't know how to determine)
As ccd cells are largely linear in response, these should very probably 
be 1.0. But i don't know if they are even used. Anyways, gamma tables 
are definitely not used for 16bit modes on gl841/2.

>   u_int16_t *red_gamma_table;  (OK NULL)
>   u_int16_t *green_gamma_table;(OK NULL)
>   u_int16_t *blue_gamma_table; (OK NULL)
> } Genesys_Sensor;



> or :
> 
> typedef struct
> {
>   SANE_Int base_ydpi;                (4800 ? : Lide90 is 2400x4800)
>   SANE_Int optical_ydpi;             (4800 ? : Lide90 is 2400x4800)
>   SANE_Int max_step_type;            (don't know how to determine)
>   SANE_Int power_mode_count;         (don't know how to determine)
>   Genesys_Motor_Slope slopes[2][3];  (don't know how to determine)
> } Genesys_Motor;

Unless you figure out multiple power modes, power_mode_count needs to be 
set to 1. This is intended for scanners that can use a reduced power 
mode for smoother head moves, when speed is not needed(high resolution 
scans with slow moving head).

The stepper motors used are capable of doing full steps or half steps, 
most of the time. the gl842 handles quarter step, gl843 seems to handle 
eighth step, too. This is reflected by max_step_type:
max_step_type ! smallest steps
       0       ! full
       1       ! half
       2       ! quarter
       3       ! eighth

base_ydpi is very probably 2400 dpi. manufacturers tend to go by the 
maximum possible value, which would be 4800 when using a 2400 dpi 
full-step drive in half-step mode. The relationship between 
optical_ydpi, max_step_type and base_ydpi is thus:

optical_ydpi = base_ydpi * 2 ^ max_step_type

The slopes-array is fixed to 2x3, but the used size is:
slopes[power_mode_count][max_step_type+1]

Each slope describes a speed slope for a specific motor setting. These 
slopes are needed for acceleration/deceleration of the scanning head, as 
the stepper motors are not powerful enough to get the head to "full 
speed" in a single step.

The backend selects one fitting the requested mode, higher power mode 
indexes give better quality but less speed, same with step modes, 
although higher step modes(higher step divider) may be forced by the 
requested mode(2400 ydpi on my scanner forces half step mode, because 
full steps only do 1200dpi).

The gl84x reads the time it needs to wait between each step from a table 
submitted by the backend. Thus, the units of the slopes reflects this: 
All "speeds" are merely times between steps.

maximum_start_speed is the maximum speed this slope can start at. This 
is the maximum speed the head can reach from a stand-still. 
maximum_speed is the maximum final speed, after doing acceleration. The 
backend may generate a slope that does stay slower than any one of 
these, but it will do a slope when the head needs to go faster than 
maximum_start_speed. The minimum_steps gives how many steps a 
acceleration to maximum_speed needs to take. When the head does not need 
to reach this speed, the backend may decide to take fewer steps. g 
brings some non-linearity.

The values here can be found by experiment, or by analyzing the slope 
tables from an usb log. The values from the windows driver may be a bit 
conservative. When experimenting, one would decrease the values of 
maximum_speed, maximum_start_speed and minimum_steps until the head 
fails to speed up, and then increase them a bit. Positioning the scanner 
such that the head goes upwards gives a nice safety margin while 
experimenting. A final warning: when doing this, you may destroy your 
scanner. Although i doubt that the loud noises from a not-moving head 
stem from slipping gears, but instead from the stepper motor itself 
oscillating back and forth.

> 
>> Guillaume Gastebois schrieb:
>>> Hello,
>>>
>>> I remember that LiDE 90 is a 2400DPI scanner. And I did nothing in code to
>>> port
>>> that. I backend ready for 2400dpi (I think so regarding portion of code) ?
>> I am not sure, as there could not happen any testing. But in theory, it
>> should work. In the future, there should be some afford made to make
>> other resolutions than 2400, 1200 and 600 work, but these 3 are trivial
>> with this chip.
>>
>>> I write 2400 dpi in genesys_sensor for lide 90. But how to know pixel number
>>> for
>>> CCD sensor ?
>> I guess the manufacturer is not lying about the density of the ccd, so
>> that should be enough. The rest of the settings is in real units. The
>> backend calculates the exact number of pixel from the density and the
>> width of the scanning area.
>>
>>> After writing 2400 dpi in sensor, I get quarter sized images !!! Why ?
>>>
>>> With 600 dpi in sensor I get full sized images with (300dpi scanning) or
>>> without
>>> half_ccd (1200dpi scanning) (with my code for gpio 14).
>>>
>>> Regards
>>> Guillaume
>> I'd first try to get the correct gpio setting for a full resolution
>> scan(i.E. at 2400dpi). If you cannot get a full-width-scan, look for the
>> DPISET register, and try half/twice the dpi there. Also, make sure the
>> DPIHW is set for the 2400dpi mode.
>> When that works, figure out how to setup gpios for half_ccd mode. From
>> the view of the current code base, you are done here. You can try to
>> find a quarter_ccd mode(which would show up as half-width in the
>> half_ccd modes), and leave a comment in the code, or even implement the
>> quarter_ccd mode for real.
>>
> 
> Yes, DPIHW is 0x80 (2400dpi)
> for 300dpi scanning dpiset is 0x258 (600). Is that good ?

correct for a half-ccd mode.

> I find that GPIO14 is quarter CCD but by testing all other unknown GPIOs I can't
> find one for half CCD !!!! Strange no ?
> 
>> Regards,
>>   Pierre
> 
> I see too that If I is image and B is black, I get for 1200dpi, 600dpi, 300dpi
> and 150dpi scanning :
> 
> 1200 :
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> BIIIIIIIBBBBBBBBBBBBBBBBBBBB
> 
> 600 :
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> BBIIIIIIIBBBBBBBBBBBBBBBBBBB
> 
> 300 :
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> BBBIIIIIIIBBBBBBBBBBBBBBBBBB
> 
> 150 :
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> BBBBIIIIIIIBBBBBBBBBBBBBBBBB
> 
> Why ?

Probably black pixels, that are not scaled with the scanning mode.

> Regards
> Guillaume
> 

Regards,
   Pierre