[sane-devel] HP Scanjet 4850 Development

Stef stef.dev at free.fr
Thu Feb 16 20:24:05 UTC 2012

Le jeudi 9 février 2012 00:03:21 Daniël Sonck a écrit :
> On 07-02-12 21:38, Stef wrote:
> > Le dimanche 5 février 2012 22:27:53 Daniël Sonck a écrit :
> >> On 05-02-12 09:01, Stef wrote:
> >> 
> >> I compiled from the latest git source code. The release that came with
> >> openSUSE did not want to work or recognize my printer.
> >> 
> >> Daniel
> >> 
> > 	Hello,
> > 	
> > 	could test that adding your scanner to this test (line 710 of
> > 
> > genesys_gl843.c) improves the scan ?
> > 
> >    /* G4050 values */
> >    if ((strcmp (dev->model->name, "hewlett-packard-scanjet-g4050") ==
> >    0)
> >    
> >     || (strcmp (dev->model->name,
> >     || "hewlett-packard-scanjet-g4010") == 0))
> >      
> >      {
> > 
> > Regards,
> > 
> > 	Stef
> Alright, I have made a simple script that calls scanimage with all
> possible combinations of scan settings (mode, resolution, bitdepth). I
> have clearly an error in my script as it calls lineart and depth
> together but somehow there is a (serious) bug in the driver. Whenever I
> call lineart together with depth, the driver actually sets the scan head
> to the beginposition but gives an error about the unused parameter. It
> doesn't return the scan head to the beginning. So as every new scan
> assumes that it is in the starting position (and it isn't far enough to
> let the scanner return the scan head self) it over-scans, and thus
> resulting in an awful bump.
	Would you mind send me the scanimage line with conflicting parameters so 
that I can reproduce the bug here ?

> But even if it is in the starting position, almost every scan resolution
> I use moves the scan head to the wrong starting position, always too far
> resulting in a dangerous overscan (it doesn't bump however).

	The geometry description of the 4850 is a clone of the G4050. I has never 
been tuned since I don't have this device to test on. The value to work on are
the one in genesys_devices.c in the hp4850 device entry:

  SANE_FIX (8.0),		/* Start of scan area in mm  (x) */
  SANE_FIX (13.00),		/* Start of scan area in mm (y) */
  SANE_FIX (217.9),		/* Size of scan area in mm (x) 5148 pixels at 600 
  SANE_FIX (315.0),		/* Size of scan area in mm (y) */

The first is the amount of distance for the head to reach scan area. Decrease 
it until scan really starts at he beginning of the scan area.

The second is left margin, and third the width. Tune width when margin is OK.

Last field is total scanarea height. Decrease it to 250 so you get sure the 
head won't bump to the end of device. Once other values are settled, increase 
it until you get the whole area scanned.

> The colors are strange too. In the folder (dss.nl.eu.org/pictures) you
> can see the results of Gray and Color mode. The second batch of scans
> are pictures of my printer-test-page as it shows all colors/Grays and
> text. Somehow my paper shows violet. That can be the paper, it does show
> a bit violet when it is being scanned. The background is clearly white
> (first couple of scans). Because I opened the lid (to see why it made
> strange noises like it was constantly bumping) the rest of the images
> have black backgrounds.

	In case of improper calibration colors maybe not good. Tuning the scanner 
geometry may help (by . You can also play with the gamma option to improves 
the result. By running scanimage like this:

scanimage -d genesys --resolution 75 --mode Color >scan.pnm 2>debug.log

You will create a debug.log and a lot of pnm files. Please send them all to 
me. I'll be able to check calibration.

> Mode Color 400dpi 16bit is pretty wrong. It moves the head forward for a
> couple of cm and then moves it back a bit and continues forward and
> reverses again (until it reaches the end).
> Mode Color 600dpi 16bit is very wrong. It moves the head forward and
> back (more back than forward). The scanned image is correctly read, the
> head isn't correctly moved.

	This is called backtracking: the computer doesn't read data fast enough, 
when its buffers are full the scanner discard data and goes back to the last 
good position. Compiling SANE using libusb-1 usually helps transfer speed. But 
at some point you may be constrained by USB bandwidth.


> If you could tell me how to solve (or try to solve) this?
> Daniel

More information about the sane-devel mailing list