Hi As you might guess, i'm having another patch ready for review.
St?phane VOLTZ schrieb: > Hello, > > I have applied your slope table patch in the experimental/genesys. I > tested > it wtih my MD6571 and everything I tried worked fine. > The 'stagger' pattern is indeed : > ...0...0 > ..0...0. > .0...0.. > 0...0... > Currently the pattern is restricted to this one: .0.0 0.0. because the old code seemed to do it that way, and there is no variable storing the actual width. > I've reread the 'genesys_read_ordered_data'. It has 2 phases. First it > fills > buffer with enough raw data for the second stage, which then copies data to > the backend. The complexity comes from all the possible cases when copying > raw data in the form required by the backend and frontend combination. One > thing that come to my mind is that splitting that copy in a dozen of simple > functions (one for each case) would be enough. But, since you're going after > something better, I'll wait for it. I doubt it is that much better. I produced about 6 new functions, all in two variants for single and double byte data. There are 5 steps now: step 0: Reading data from scanner. Delegated into its own function, but may be moved back. step 1: genesys_reorder_components_(cis|cis_bgr|bgr)_(8|16) convert byte order, planar and bgr data. genesys_reorder_components_endian_16 converts byte order, and is only available on big endian systems. step 2: genesys_reverse_ccd_(8|16) reverses the effects of ccd layout. It takes line offsets per component for multiple pixels, thus doing line distance correction and unstaggering in one pass. We could convert any stagger pattern (up to 4 pixels width currently) that way. step 3: genesys_shrink_lines_(8|16) shrinks/enlarges lines. step 4: copy result to frontend buffer. This is needed because the conversion functions work on line aligned data, and we may have lines longer than 32768 bytes, thus needing a output buffer. I used the preprocessor to generate the 8/16 bit versions, and i think it is a good idea to put that into an extra file, leading to two extra files. I could expand genesys_conv.c to contain all the mentioned functions, but then there would be two very similar implementations to be kept in sync. The functions may be useful for other backends, too. I changed the way the information about the format of the scanner output is stored. I think it is more understandable this way. I needed 4 buffers. To handle that efficiently i added a set of buffer management functions. Then i completely removed dev->exposure_time. It was still used at quite some places. If that is not okay, i can revert that. Finally i moved the byte order detection from run time detection to compile time detection, using the WORDS_BIGENDIAN macro defined(or undefined) in include/config.h. > > I think it is high time you get CVS access to SANE. The one thing we > will > have to mind is to discuss or warn for changes in the common code. Simple > fixes and chipset specific changes should be OK. How do i get cvs access? I am already having a user on alioth. > > I am going to tune the gl646 part for the HP2400. I believe that the > changes > I have in mind (mostly constants tweaking) shouldn't disturb your current > work. > > Regards, > Stef > If this patch is okay, we need to discuss calibration. My scanner has as black and a white strip at the beginning of the scanning area, while other scanners seem to be different. I also need additional calibration steps to calibrate the led exposure times to get nearly equal scanning results for all three colors before doing shading. That improves the quality of 16bit scans. The attached patch still is not moving the gl841 part to any working state. As soon as there are checkins into experimental cvs i will update the patch on my website. It still is too large for this mailing list. Regards, Pierre -------------- next part -------------- A non-text attachment was scrubbed... Name: genesys_conversion.diff.gz Type: application/x-gzip Size: 16097 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20050904/ff511c15/genesys_conversion.diff-0001.bin From mmuel...@gmx.de Mon Sep 5 13:01:28 2005 From: mmuel...@gmx.de (Markus Mueller) Date: Mon Sep 5 13:01:59 2005 Subject: [sane-devel] Astra 3400 Mac OS X References: <20050904180615.gb22...@meier-geinitz.de> Message-ID: <26036.1125925...@www72.gmx.net> > --- Urspr?ngliche Nachricht --- > Von: Henning Meier-Geinitz <henn...@meier-geinitz.de> Hi Henning and all the others! Thanks for your hints!! > > > [sanei_access] sanei_access_lock: open >/usr/local/var/lock/sane/ > > LCK..libusb:005:002-1606-0060-00-00< failed: No such file or directory > > [plustek] sanei_access_lock failed: 11 > > This looks a bit strange. Does /usr/local/var/lock/sane/ exist and can > files be created by the user you run the frontend with? > This was indeed the problem. /usr/local/var/lock/sane/ didn't exist. After creating it and giving the necessary rights, it works (althought the time between the command and the actual starting of the scan is VERY long, but maybe I can fix this with changing some options in Plustek. But I feel a little bit uncomfortable, since I created directories manually, that should be created automatically during installation. So wonder what went wrong. So far there are no error messages in DEbug Mode. Thanks a lot. Best wishes Markus -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl