[sane-devel] Reflecta ProScan 7200

[Michael Rickmann]

Hi Jan,
sorry for the very late reply. I have been rather busy with different 
things and have not done very much on the PIE backend.

Am 02.06.2011 21:37, schrieb Vleeshouwers, J.M.:
> Hi Michael,
>
< large snip >
> wait loops for the device to get ready. I (accidently) noticed that the
> available-lines value in the PARAM response actually works. If you start
> a scan (COPY), don't read the available scanned data, but repeatedly call
> PARAM, the number increases. For larger resolution settings the scan head
> will eventually stop moving, long before it has scanned the whole slide.
> The number of available lines stops increasing, and the scanner hangs.
Good to know. The available lines value seems to be important when we 
reorder the R, G, B, I lines which may come rather delayed relative to 
each other and are equal in number only at the end of a scan.
> Byte 16 of the DC-settings has something to do with this. I overlooked
> it, but for larger resolutions this byte has several different values between
> 0 and 8 in the snoops. Setting the value to 0 for a 7200 or 3600 dpi scan
> results in an error after reading about 2Mb of data.
> You suggest motor settings, but might it be related to how the scanner treats
> its internal buffer memory?
>
I made a few test scans using Windows/Silverfast which offers a "lamp" 
option which just prolongs our texp values. Byte 16 seems to be used to 
limit the transfer rate to about 1.5 MB / sec. The actual value depends 
on the line width, the bit depth, the (maximal?) texp setting, and 
whether ifrared is transmitted. I think the byte takes care of the 
capacity of the GL660USB chip by slowing things down if the data rate 
becomes to high. I have put an empirical calibration routine ( 
pie_usb_calicalc_slow_down in pie_usb.c, 
http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/status-110711/files.tar.gz 
). It allows me to complete most scans at 3600 dpi, 16-bit RGB or RGBI 
now. The only other change I put into the backend is that it dumps all 4 
colour planes to the /tmp directory now, so that I can look at the 
infrared which is currently not supported in the SANE specification.
> For a first draft document: www.stadspartijeindhoven.nl/jv/Reflecta7200.odt
>
Looks rather impressive and I agree with most of it. What the priority 
list is concerned I immediately got hooked to the last point, scratch 
removal, see my next post.

In practice I have a nasty problem that cancelling a scan frequently 
locks the scanner. I think that killing the reader process leaves quite 
a few bytes unread which the scanner has to get rid of. In order to 
maintain the general layout of the reader routine which is already 
overly complex because of the reordering I would like to switch to a 
reader thread instead of the current fork / pipe mechanism.

When you ask when our work is to be submitted officially to SANE, there 
is a general decision to be made, extend the existing backend or make a 
PIE2 one. There are such a lot of ifs in the original PIE backend now 
that I can not guarantee that it is still working for the original SCSI 
scanners. But they seem to be mostly in hardware heaven by now. I missed 
an Adlib one which was offered on ebay.ch in April.

I think with the gamma we might just convert into approximate sRGB and 
leave the rest to the frontends. That would make the output somewhat 
NIkon-like (compare Nikon LS with PrimeFilm 3600 Pro at 
http://www.testdata.coloraid.de/ ) and it would provide a constant for 
colour profiling.
> For some experiments with the infrared:
> www.stadspartijeindhoven.nl/jv/InfraredTests.odt
> They cover bytes 18 to 22 of the SCSI-DC-structure. Byte 21, which I named
> "val", remains a mystery. The other ones behave as expected.
>
> Yours,
>
> Jan
Before getting more precise about when submitting the stuff I would like 
to get an idea of the general outline of the backend after having done 
a  lot of cleaning up. I think that we have addressed most of the 
critical hardware points by now.
Regards
Michael