oh, and i have an unsupported ma1509 ADF machine right here, so i might be able to help you a little, though my time is quite limited...
allan On Mon, May 12, 2008 at 10:01 AM, m. allan noah <kitno455 at gmail.com> wrote: > sniffer: http://www.pcausa.com/Utilities/UsbSnoop/default.htm > > see also http://www.sane-project.org/contrib.html and > pirsoft-dsl-dropzone.de/scanner-technical.pdf for more info > > allan > > On Mon, May 12, 2008 at 8:14 AM, Ekkehard Morgenstern > > > <ekkehard at ekkehardmorgenstern.de> wrote: > > > > Thank you! :) > > > > How do I log USB communication in Windows? > > > > I might try to implement what you said sometime. I love controlling > > devices! :) > > > > I also have to analyze the source code of the backend. Its implementor > > already used reverse engineering data, perhaps code that I'd need is > > already there. > > > > I've never done driver development on Windows, Linux or BSDs, but I'm > > certainly interested in it! :) > > > > And since SANE operates on top of normal OS services, this would be like > > an initiation rite for me! ;) > > > > > > > > On Mon, 2008-05-12 at 07:51 -0400, m. allan noah wrote: > > > The results might be caused by poor (or no) CIS calibration being done > > > by the backend. You could try getting a trace of the device in action > > > with the windows driver, and investigate adding the calibration steps > > > to the backend. > > > > > > generally this involves doing several small scans of a white area > > > under the shell of the scanner, with and without the lamp on. this is > > > usually pretty easy to identify in the logs. interpreting it is a > > > different matter... :) > > > > > > allan > > > > > > On 5/12/08, Ekkehard Morgenstern <ekkehard at ekkehardmorgenstern.de> > wrote: > > > > > > > > It's the ma1509 backend. > > > > > > > > I've already seen that there's a possibility to provide gamma > correction > > > > tables and such to SANE from within a backend. How does it work? > > > > > > > > I'm not sure whether the poor results of my scanner are the result of > > > > hardware aging, or if it's just because the backend seems to pass on > the > > > > data from the scanner chipset unchanged. > > > > > > > > It's an LED scanner, so there must be a set of photo diodes or photo > > > > transistors somewhere. It appears as if the scanner sends the data in > > > > raw form, unadapted to the characteristics of the semiconductors. > > > > > > > > Distribution of RGB values across their channels suggest that the > data > > > > should be scaled or transformed somehow. I spent a whole night this > > > > weekend trying to figure out some formula that would solve the > problem, > > > > but I didn't find a solution. > > > > > > > > Instead, I wrote this program to simply compute the difference > between a > > > > blank page and the color white. The program generates one line of > > > > averaged out scaling data, which is stored in the file "white.shape". > > > > I'm not sure whether the data can be made constant. If it were to be > > > > included in the backend driver, it has to be fairly constant over all > > > > scanners of that type. > > > > > > > > After all, the Windows driver must do the same thing somehow! ;) > > > > > > > > > > > > > > > > On Sun, 2008-05-11 at 15:42 -0400, m. allan noah wrote: > > > > > > > > > Ekkehard- another choice might be to do this sort of calibration > > > > > inside the driver in sane, but that would require becoming familiar > > > > > with the code of the sane backend which drives the scanner.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > "The truth is an offense, but not a sin" > -- "The truth is an offense, but not a sin"
