[sane-devel] Reflecta ProScan 7200
mrickma at gwdg.de
Mon Jul 11 16:09:27 UTC 2011
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,
). 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
> For some experiments with the infrared:
> 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.
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.
More information about the sane-devel