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
