Hello all, I have a Canon CanoScan D646U which is currently unsupported. It is a flatbed scanner with a USB interface. I did try using the canon630u backend but it didn't work (although perhaps there are various configuration tricks which might make it work? I don't know). Although I have no experience with scanners or with writing device drivers in general, I do have a solid background in programming and linux, and relish a good challenging problem, so I (along with a friend) have been toying with the idea of writing a backend, because, well, it would be cool. (= So I thought I would first toss out this message to see what guidance anyone might have to offer. Has anyone worked on this scanner already? Does anyone have any guesses as to what writing a backend for this scanner might entail? Is there any code I can likely reuse (e.g. the code from the canon630u backend)? Any other help/advice/links to useful information anyone has to offer?
Thanks in advance, -Brent Yorgey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20051214/8ae9232f/attachment.htm From lauri.pirtti...@luukku.com Wed Dec 14 21:05:04 2005 From: lauri.pirtti...@luukku.com (Lauri Pirttiaho) Date: Wed Dec 14 21:05:14 2005 Subject: [sane-devel] Progress report on CanoScan 3200F: Now about shading Message-ID: <1134594304223.lauri.pirttiaho.127717.kwl5bd3w6crvlh6zsls...@luukku.com> Progress report on CanoScan 3200F --------------------------------- I have now been working on color scanning involving the internal black/white shading compensation system. First, it was somewhat difficult to figure out some problems in the scan head sticking at the beginning. This led to two findings. First was that the byte 26 of command vl=0030 has something to do with the maximum stepper motor current -- maybe a current limiter value or a voltage. Anyway, the procedure for this apparently motor affecting value is as follows: Before scan (or any motor movement) bits 5-4 of FFB0 are set (i.e. @FFB0 |= 0x30). That register appears to be direction register of general purpose IO. The corresponding data register is FFB1 so the new motor control value is programmed as @FFB1 = @FFB1 & 0xCF | 0xn0, where n is the wanted value 0, 1, 2, or 3. Typically 3 is used for movement (like head home) and before scan. 3 is also used for 75 dpi scan. 1 is used for 1200 dpi scan and 2 for all others. So the byte 26 of vl=0030 command is 0x10 for 1200 dpi, 0x20 for 150/300/600 dpi, and 0x30 for 75 dpi. Also the main lamp and TA lamp are controlled though that same GPIO. Main lamp is connected to bits 3-2 and TA lamp to bit 7. Besides those register FFBF seems to be also somehow connected with the main lamp. Since the light output seems to be lower when the lamp is lit from there and not from FFB1, it may be that FFBF is somehow related to the PWM control of the lamp mentioned in the M5623 product brief. The second finding was that the speed curves I mentioned in my previous posting have to be more carefully designed. I.e. too quick changes in acceleration and speed may drop the motor out of phase and the head will stall. Then about the more important finding, the shading control. First, however, details of the byte 4 of vl=0030. That is color mode selection. Values 0-2 are gray scale scans using the reg/green/blue lines, respectively. Value 3 indicates RGB color scan. Byte 6, low 4 bits of which go to register FFE1, seems to control the shading/gamma processor. These are presently unconfirmed but it seems that bit 0 is used to switch on gamma processing and bits 1 and 2 seem to turn on the shading processing, maybe offset on and gain on bits. With bit 3 I have not yet gotten any effect. Now, to the shading processor. It operates so that for each color, the gain and offset values are programmed to 12 registers as 16-bit values. The registers are FF40-FF45 for the gain (R,G,B 2 bytes each LSB first) and FF46-ff4B for the offset. This value is used for the first pixel on each line and the algorithm is the traditional one where from the data coming from AFE the offset is first subtracted and then the result is multiplied by 65536 and divided by the programmed gain (i.e. inverse gain) value. For each subsequent pixel a 16 bit offset value is taken from the data written to memory at address 0x080000. Lowest 12 bits of that value are a 2's complement value added to the gain and highest 4 bits are a 2's complement value added to the offset. The procedure the driver seems to use to determine the offsets and gains is, that it scans several lines first with lamp off and then with lamp on. From the lamp-off values the dark offset is calculated by averaging the lines and then smoothing the curve along the CCD line (pixel to pixel) using some kind of possibly polynomial fit. The gain values are then adjusted so that the average lamp-on values would scale to about 90% of maximum. This is not the exact procedure the driver uses but sufficiently close to the right one so that the image quality is OK. Having figured out that, I will now go back and try to put all together. I have still problems with motor parameters since the interrupt interval seems to affect the exposure time also, and I have not yet figured out how the control vectors at FA00 and FA80 are used to control the scanning. Therefore, the playback of those vectors I get from my XP machine (it has USB 2.0) seems to run the scanner too fast for my Linux box (only USB 1.1 interfaces), and I get a lot of back-tracking. I have not yet tried with my newer Linuxes which have USB 2.0... I think I will try to figure that out, too, before making a stand-alone proof-of-concept trial program. So, still a lot to do. With best regards, Lauri Pirttiaho Oulu Finland ................................................................... Luukku Plus paketilla p??set eroon tila- ja turvallisuusongelmista. Hanki Luukku Plus ja helpotat el?m??si. http://www.mtv3.fi/luukku