[sane-devel] Reflecta ProScan 7200
mrickma at gwdg.de
Fri Apr 29 10:24:57 UTC 2011
Am 28.04.2011 21:37, schrieb Vleeshouwers, J.M.:
> Hi Michael,
> A last update with:
> - GEM (grain equalisation) settings;
> - a set of default scans with very different slides;
> - a set with various crop settings.
> Nothing spectacular. GEM is done in software completely. Default scans with different slides (and a scan without slide)
> do not appear to have much effect on the data transfered. I suspected the 11-byte DD-response to contain information
> about the presence of a slide, but I was wrong. Requesting partial scans results in different values sent to the
> scanner in SET_SCAN_FRAME (SCSI 0a-12), and corresponding variations in the data read by PARAM (SCSI 0f), as might be
> expected. See http://www.stadspartijeindhoven.nl/jv/SettingsAnalysis.ods for the details.
> I think I have pretty much looked at all aspects the Windows-driver and Cyberview have to offer. Did I miss anything?
Thank you! No, we will have to experiment to ask specific questions.
Then we can do a snoop to look up how PIE handles a certain condition.
> I have not extracted photographic data from all snoops, but the ones I've seen are all dark to very dark, some use no more
> than 20% of the available range. Even if the scanner will not accept GAMMA-settings (the pie.c-way or in another way),
> we should still be able to use the scanner's output range better than this.
PIE seems to have left room for improvements there and programs as
VueScan and Silverfast and us. I guess a combination of emulated gain as
Alan suggested and exposure time will come out in the end.
> With respect to the "quality" setting: you're right, it's MODE_SELECT byte 9, ("required speed"), not 7.
> I never quite listened to the sound the scanner makes, but it makes sense that a larger exposure time results in a lower
> scanner tone, since the stepper motor steps in a slower pace. It should also be related to a lower gain setting, since
> the CCD receives more light.
> The details remain to be uncovered. I wonder why the scanner would have any need for a "quality" bit at all, if
> exposure time, gain and offset can be set elsewhere and in more detail. I also wonder why there is some seemingly
> random variation in byte 0&1 of the DC-output (red_texp), for example in the default-runs (names with _df): these all
> started with switching on the scanner and setting all options off. (And these are not the only questions...)
> Apart from the calibration data (1+13+31 lines) there is also the COPY input (SCSI 18) which has not had any attention
> yet. What could be the use of sending 1 byte of information for each CCD-pixel, with no more variation than 0x70 or 0x00?
Yes the MODE_SELECT 9 is still enigmatic. I am glad to have it working
at the moment. As to the randomness of the *texp values, I have mainly
observed them for the low bytes. There is some variation of the mean RGB
values between scans when reading the calibration lines. I guess it is
propagated to the calibration setting.
> I would like to experiment a bit further. You offered to help me get the SANE backend compiled from source, and from
> what I read on the internet, that would help me a lot. The alternative would be to build a very lightweight libusb-based
> program to access the scanner directly. Is there anything this would allow me to do which would not be
> possible (or more difficult) in SANE?
I must confess that the only programs which I use for experimenting are
Xsane and gedit. That is fastest for me. I think that we have passed
already the lightweight stage. As we can extend an existing backend
libsane's overhead is not to difficult to handle. Ok and now the build
instructions, be warned.
I work with 64-bit Ubuntu 10.10. I will try to explain how I would do it
for Lucid. First you need to install some packages for building:
sudo apt-get install checkinstall build-essential dh-make devscripts
fakeroot patch diff patchutils git
Then you need recent sane-backends. Install the ones from
https://launchpad.net/~robert-ancell/+archive/sane-backends as detailed
in http://ubuntuforums.org/showpost.php?p=10526638&postcount=31 step
1). In addition install libsane-dev from the ppa. Now check that the
libraries the SANE build may depend on have been drawn in by
libsane-dev, copy-paste the following into one line:
sudo apt-get install libv4l-dev libgphoto2-2-dev libltdl3-dev
libjpeg62-dev libtiff4-dev libusb-dev libieee1284-3-dev libcam-dev
libavahi-client-dev gettext texlive texlive-latex-extra autotools-dev,
pkg-config chrpath xutils-dev
Make a directory in which you will build and host all the stuff which
will accumulate. I call it rex here (short for Reflecta experiments). cd
rex and get current SANE git: git clone
git://git.debian.org/sane/sane-backends.git . After a while there will
be a sane-backends directory. I have archived it and renamed the
original to my-sane-backends with which I work. Now get my files from
. hx2pnm.c you do not need at the moment, I made it to convert snooped
hexadecimal numbers to an image. Makefile.am, pie-scidef.h, pie.c,
pie.conf.in, pie.h, pie_usb.c need to be copied to
my-sane-backends/backend, pie.desc to my-sane-backends/doc/descriptions.
Now you will need to adapt the whole stuff to your build environment. "
cd my-sane-backends " and do a " autoreconf --force ". There may be some
warnings, from which the ltmain.sh one may be critical. You should keep
the git tree in my-sane-backends free from all the stuff you have to
build. So, make another directory rex/build , I made it at the same
level as my-sane-backends . " cd build " and "
../my-sane-backends/configure --prefix=/usr --sysconfdir=/etc ", then "
make ". For installation you have to do the following only once:
As you superuser save /lib/udev/rules.d/40-libsane.rules in a different
directory and copy rex/build/tools/udev/libsane.rules to
/lib/udev/rules.d/40-libsane.rules or how the original was called. Copy
rex/build/backend/pie.conf to /etc/sane.d/pie.conf . Place the following
script in rex - I named it inst - adapt it to your directory tree,
outcomment the rm and ln lines and make it executable:
cp rex/build/backend/.libs/libsane-pie.so.1.0.23 /usr/lib/sane
#ln -s /usr/lib/sane/libsane-pie.so.1.0.23 /usr/lib/sane/libsane-pie.so.1
cp rex/build/backend/.libs/libsane.so.1.0.23 /usr/lib
#ln -s /usr/lib/libsane.so.1.0.23 /usr/lib/libsane.so.1
Run it once as sudo rex/inst and then comment the rm and ln lines again.
You may have to do a sudo ldconfig. And for udev to pick up your new
rules it is safest to reboot.
Plugin your scanner, switch it on, wait for the calibration to finish
and do the usual sane-find-scanner and scanimage -L. It should be found.
Then open a console, set debug output to full " export
SANE_DEBUG_PIE=255 " and scan " xsane 2> pex/dbg ". Do not use RGBI yet.
It will hang the scanner and you will have to powercycle it. You can
lookup pex/dbg for what the backend has done or where it got stuck.
If you wish to experiment have a look at line 731 and around in
pie-usb.c. You can write a textfile /tmp/calbytes.txt with 12
hexadecimal 8-bit numbers in it which strtol can interpret ( 0x25 0x25
0x28 ....). Xsane will pick them up at the next scan.
If you have made changes to the code close xsane " make -C pex/build "
as a normal user, then " pex/inst " as superuser and restart xsane.
This has become quite long, I hope it gets you started with your scanner
and SANE. If you need more help let me know.
More information about the sane-devel