[sane-devel] Reflecta ProScan 7200

Fri Apr 29 10:24:57 UTC 2011

Hi Jan,

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?
>
> Yours,
>
> Jan
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 
http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/status-270411/files.tar.gz 
. 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:
#!/bin/bash
cp rex/build/backend/.libs/libsane-pie.so.1.0.23 /usr/lib/sane
#rm /usr/lib/sane/libsane-pie.so.1
#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
#rm /usr/lib/libsane.so.1
#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.
Regards
Michael