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