Fwd: Re: [sane-devel] Lexmark experimental backend]

[Stéphane VOLTZ]

Le vendredi 9 juin 2006 03:44, Fred Odendaal a écrit :
> Stef,
>
> I tried a few scans with the latest code. It seems to find the start
> position much better. It even works when I have Top-left x and y set to
> something other than 0, which was broken for me before.
>
> However, the colours are way off for my scanner. All the colour scans I
> do are saturated to blue (white becomes blue). This becomes worse as I
> increase the resolution. Also, there is a lot of back tracking at 300dpi
> for a full page scan. I don't think the acceleration curves have been
> set correctly for this resolution and image size. Actually, it's
> probably just width and resolution to determine the acceleration curves.
>
> If you need me to do any testing, or send you any logfiles let me know.
> Fred.
>
> Stéphane VOLTZ wrote:
> > Le Dimanche 28 Mai 2006 20:20, Fred Odendaal a écrit :
> >> Stef,
> >>
> >> You are correct about the dot. I've attached 2 files:
> >> find_start_lexmark1.pnm - This was with SANE_DEBUG_SANEI_USB=255
> >> find_start_lexmark2.pnm - This was with SANE_DEBUG_SANEI_USB unset.
> >>
> >> As you can see the picture gets better with usb logging turned off. I
> >> think the real problem function is
> >> sanei_lexmark_x1100_search_home_bwd(). It should have stopped the scan
> >> head and positioned it inside the dot. The white space at the top of
> >> each file is the distance past the dot that the scan head moved in the
> >> reverse direction. In this function after the scan is stopped from
> >> moving in the backward direction it is moved forward half the distance
> >> of the dot plus the maximum no. of lines the buffer will hold. This is
> >> done by the call to sanei_lexmark_x1100_move_fwd(). When I comment this
> >> line out the picture gets even better. In other words, this function
> >> isn't moving forward, but continuing backwards making our position even
> >> worse!
> >>
> >> The sanei_lexmark_x1100_find_start_line() function is working as it
> >> should. It simply scans what should be enough lines to scan past the dot
> >> into white space and return the number of white lines past the dot.
> >> Since the distance to the scanning area from the dot is known we simply
> >> subtract how far past the dot we've moved from this number to see how
> >> far we still have to go.
> >>
> >> regards,
> >> Fred O.
> >
> > 	Hello,
> >
> > 	you wre right, the trouble was with 
> > sanei_lexmark_x1100_search_home_bwd() which was scanning too far. To
> > correct it, I made it read only one line of data (2500 bytes) at a time.
> > So when it finds the dot and then stop, it is right on it. So we don't
> > need to move forward a little. Now origin finding is slower but much more
> > reliable.
> > 	This change uncovered a bug in the way I modified rewind. So I had to
> > change it. It now goes back by the bottom right y coordinate plus a fixed
> > amount which is the distance between start of visible area and the
> > "origin dot". I tweaked a little the calibration values. Picture are now
> > close to the quality of my other scanner.
> >
> > 	I think that the current version is in good shape.
> >
> > Regards,
> > 	Stef
> >
> > -------------------------------------------------------

	Hello,

	both X1100 and A920 share the same motor, so I didn't change a thing motor 
related. In fact the back tracking you have is due to the software shading 
correction which slows down data transfer, thus leading to the head stalling 
until already sent data is processed. There isn't much to be done about that, 
maybe a complete rewrite of data reading during scan could help a little, but 
shading correction must happen in the backend.

	So I believe the last issue to fix is calibrating the backend for the X1100 
model. The harcoded offset and gain values for it in the current backend are:
  75 dpi: 0xa1,0x9d,0xa3   0x0a,0x0b,0x06
 150 dpi: 0xa1,0xa1,0a1    0x0a,0x0a,0x06
 300 dpi:  0xa1,0xa1,0a3   0x0a,0x0a,0x06
 300 dpi:  0xa1,0xa1,0a3   0x0a,0x0a,0x06
1200 dpi:  0xa1,0xa1,0a3   0x0a,0x0a,0x06

	What is to be done in the experimental backend is to tune the values in 
lexmark_devices.c to make the calibration functions find similar values. Here 
are the constants:
static Lexmark_Sensor sensor_list[] = {
  {
  X1100_SENSOR,
  /* offset calibration */
  12,
  /* gain calibration */
  150, 150, 150, 150,
  /* shading correction */
  260, 260, 260, 260
  },

 	When doing a scan at the choosen dpi with full debug messages, there will be
a line:
lexmark] sanei_lexmark_x1100_offset_calibration: offset=(0x7f,0x7e,0x7f)
	You first have to find the offset threshold that will give an ~0xA1 offset.

	Once offset is correct, then you'll have find the target for gain 
calibration. If the debug message:
[lexmark] sanei_lexmark_x1100_gain_calibration: gain=(0x17,0x17,0x17).
gives value too high, decrease the target for the corresponding value, else 
increase. Since your scanner uses a gain quite lower than other channels, I 
expect you'll only have to decrease significantly the blue gain target (hence 
the blue tint you currently have).
	Finally you can change the shading calibration targets to fine tune it. 

	BTW, I gave back the A920 that was lent to me but I will still assist for 
giving the experimental version a final push so that it can be included after 
the 1.0.18 release this summer.
	
Regards,
	Stef