[sane-devel] Backend for plustek Opticbook 3600

[stef]

Le jeudi 11 février 2010 19:50:25, vous avez écrit :
> > 	Hello,
> >
> > 	I am facing the same issues than you while adding support for the
> > HP3670. I eventually found that one of my decoding script was buggy and
> > hide most of AFE accesses. I have appended the fixed version. By decoding
> > usbsnoop again, you may find more AFE writes to be coded in backend. That
> > may fix the red tint issue you have. I wouldn't be surprised if only
> > write to red gain was showing in decoded log, leaving other channels
> > untouched.
> 
> Ok I have decoded another log file using this revision, you are correct
> there are many more writes to the fe showing up but they do not really
> mean anything more to me :(. I have attached the fe_writes.log file,
> which is just a straight grep of the fe writes with the new decoded log
> file. If you could look at it and tell me what you think is happening,
> the only reasonable things I can gather is that there are:
> 
> * init style writes (0x00 -> 0x70, 0x01 -> 0x80, everything else -> 0x00)
> * possible offset settings (0x05-0x07 seem to be set to 0x80 and 0xff
> repeatedly)
> * offset (0x05-0x07) and gain (0x02-0x04) seem to be set arbitrarily at
> various times.
> 
> I'm not sure if any of this is relevant but whenever I set the
> offset/gain values in genesys_devices they seem to make little (if any)
> difference to the scans.
> 
> > 	You'll also have to look at the base gamma coefficient in the
> > Genesys_Sensor entry for your model.
> 
> I've had a look at this and I take it you mean this section:
>    float red_gamma;
>    float green_gamma;
>    float blue_gamma;
>    uint16_t *red_gamma_table;
>    uint16_t *green_gamma_table;
>    uint16_t *blue_gamma_table;
> 
> I've tried changing the floats but there doesn't seem to be much
> difference, maybe I should wait until I fix the shading issue then tweak
> this?
> 
> I assume the gamma_table entries are just initialisers for the tables.
> 
> > 	When doing a calibrated scan, the REG01_DVDSET bit is set to activate
> > shading calibration. Clearing it may side step issues with shading
> > calibration, but defeat the purpose of calibration.
> 
> I was slightly worried that's what I had done here, i've restored it to
> the original values :P
> 
> > When tuning shading calibration, you must
> > look at the black/white_shading.pnm and black/white_average pnm files
> > that are written when full debug is enabled. With proper offset and gain
> > values, you must have a full black picture (with some values slightly
> > above 0) and a full white one. If not, the computed shading calibration
> > coefficient will be bogus and you'll get black scans.
> >
> > Regards,
> > 	Ste
> 
> Ok i've also attached the black/white_shading/average files. If I
> understood you correctly the black_shading.pnm should be all white and
> not the pretty purple colour it is now and conversely the white should
> not look as it does. I have tried altering the offset and gain in
> gen_devices but this doesnt seem to do anything :(. Any other
> suggestions about how I move forward with the shading? I think as soon
> as the shading is sorted I might be there with this project and ready to
> commit to the dev version.
> 
> Also I currently have OFFSET_CALIBRATION and DARK_CALIBRATION flags set
> for the scanner, how do I know if I should be using these (as opposed to
> COARSE_CALIB and DARK_WHITE_CALIB)?
> 
> Sorry I have given you quite an essay to read there but at the minute I
> have a few assignments to deal with so i'm just trying to juggle
> everything but again thanks for all the help and time you have given me.
> One other thing I wanted to ask is about a new release? I've seen a lot
> of chat on the mailing list about this but I just wondered if you knew
> any more specifics?
> 
> I only ask because I am taking this project on as part of my University
> course and the ideal end result for me is to have the drivers present in
> a SANE stable release,so if I could do this by the next release that
> would be perfect :)
> 
> Thanks
> 
> Chris
> 
	Hello,

	regarding the AFE writes, judging by the AD9826 data sheet the writes to 
addresses 0x02-0x04 are R, G and B gains. The interesting thing is that red 
gain value 0x32 is higher than the 2 others (0x1e). So a red tint seems 
sensible. Personally, I would try to set them all to 0x32 (preferably) or 0x1e 
and map the gain array to these addresses. The other writes at 0x05, 0x06 and 
0x07 are for offsets. For instance the sequence of AFE writes matches it, wee 
see gains set to 0 and various offsets tried. Then gains are set half range 
(0x80) and new offsets are tried. Looks like offset calibration for me. The 2 
remaining addresses are for AFE configuration.

	For shading calibration, GENESYS_FLAG_DARK_WHITE_CALIBRATION would allow do 
calibrate in one pass and generate 'black' data using dark areas. To my 
opinion, GL842 scanners need really good black data to do proper shading 
calibration, so I'd recommend using the GENESYS_FLAG_DARK_CALIBRATION flag 
instead. Once gains are good, you'll have a better reference white scan. But 
the white_shading.pnm shows there is a black line in the scanned area. 
Scanners have often different calibration area (located under the roof, can be 
seen by disassembling the scanner, or doing an uncalibrated scan with 0 y 
offset in genesys_devices struct). While the packaging may slightly vary from 
one model to another, this black line is always at the same distance from the 
scanning area. See GENESYS_FLAG_SEARCH_START flag. It also 'tells' where the 
white calibration is located. You'll have to get sure that the shading 
calibration scan only a white area.

	One more model supported in the stable release would be a nice thing indeed.

Regards,
	Stef