[sane-devel] Reflecta ProScan 7200

[m. allan noah]

Those are some really complicated instructions :) You might try these instead:

1. install the libusb-dev package (or libusb-devel, not sure what your
version of linux calls it)
2. install gcc package and it's required dependencies (though it's
probably already installed)
3. download latest sane-backends from http://www.sane-project.org/snapshots/
4. tar xzf sane-backends...
5. cd sane-backends...
6. run (all on one line):
 BACKENDS=pie ./configure --prefix=/usr --sysconfdir=/etc --disable-locking
7. make (then wait awhile)
8. copy the file backend/.libs/libsane-pie.so.1.0.23 over top of
the copy provided by your distro, probably
/usr/lib/sane/libsane-pie.so.1.0.20 (or .21) You can save the old
one before you overwrite it if you want.
9. test with scanimage or xsane and various options.

Only step #8 needs to be done as root. After a backend modification,
you start at #7.

Also note that there is a new library in sane, sanei-magic. It is used
to provide some simple image manipulation routines. It has code to
generate lookup tables for brightness/contrast, for software emulation
of missing hardware features. You could extend that routine to also
use gamma argument, and use that in pie backend.

allan

On Fri, Apr 29, 2011 at 6:24 AM, Michael Rickmann <mrickma at gwdg.de> wrote:
> 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
>
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>            to sane-devel-request at lists.alioth.debian.org
>



-- 
"The truth is an offense, but not a sin"