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"