Am 11.04.2011 00:03, schrieb Jan Vleeshouwers: > Michael Rickmann<mrickma<at> gwdg.de> writes: > >>> allan <---- snip
Hello Jan, >> Michael, > Good to hear you are starting to get some response from the scanner. Could you > tell me how you wrapped the SCSI-commands? Have a look at http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/status-110411/files.tar.gz . They are the files which I have used over last weekend. In pie-usb.c you find a function pie_usb_scsi_wrapper from which I branch into the USB code. This function takes the same arguments as sanei-scsi-cmd. In sane_init and sane_start I first try to attach a SCSI scanner, if that fails I try the same for USB. Depending on the outcome I set a function pointer to either of the afore mentioned functions. With the code contained in that download I can get some images using xsane, still to dark, faked calibration, frame a bit too high, too slow, 8-bit only, but at any resolution and quality settings. > I have done a couple of basic scan runs with varying resolutions, and compared > the logs to what SCSI-2 and pie.c have got to say. For a rather detailed > update > see http://www.stadspartijeindhoven.nl/jv/DataAnalysis.ods. That is very valuable. I have not done yet such a systematic investigation. A lot of things become clear in your account. > Your INQUIRY-results > match what I found, but I also see several options not accounted for in the > pie-backend. What is interesting about the INQUIRY-command is that it is > issued > repeatedly although it always returns the same information. I haven't been > able > to figure out why that is. Might the device driver be trying to find the best > way to communicate with the scanner? That seems harmless, it works with a single INQUIRY as well. I guess it is just different Windows dlls which require that information but do not communicate it. > I'm able to interpret many other logged activities as well, but there are > still > large holes, especially with respect to SCSI-commands D7, DC and DD. > The DD is also harmless, I named it PIE_READ_STATUS in my code but I do not use it yet. It will become important for error handling during the initial internal calibration of the scanner and lamp warm up, I guess. The D7 (named PIE_READ_CALIBRATION) and DD (named PIE_WRITE_CALIBRATION) commands are really nasty, as they seem to be used for calibration. I tried to formulate a simplified flowchart of what happens when preview and an image at normal quality is aquired: SET_EXP_TIME x3 SET_HIGHLIGHT_SHADOW x3 READ_CAL_INFO SET_SCAN_FRAME CUSTOM_READ_d7 CUSTOM_WRITE_dc MODE SCAN READ 1 line TEST_UNIT_READY READ 13 lines CUSTOM_READ_d7 CUSTOM_WRITE_dc READ 31 lines COPY PARAM READ image CUSTOM_WRITE_d2 SET_EXP_TIME x3 SET_HIGHLIGHT_SHADOW x3 READ_CAL_INFO SET_SCAN_FRAME CUSTOM_READ_d7 CUSTOM_WRITE_dc MODE SCAN COPY PARAM READ image CUSTOM_WRITE_d2 The double indented lines represent the period when the Win-progs say calibrating. Interestingly, my scanner does not move during that period. The lines which are read must have been cashed by the scanner. Moreover, the scanner does not accept calibration data as sent by the SCSI routine pie_perform_cal. It does not accept the wrapped SCSI write, just anwers 03 02 (error). > I'm currently checking where different settings can be traced back in the > logs. > With respect to the "color depth" option (8 or 16 bit) in Cyberview, I > expected > large differences in log file size but actually there is almost none. It seems > as if Cyberview always requests a depth of 16 bit from the scanner, but > post-processes it to 8 bits afterwards, if asked for. I think that aquiring 16-bit is preferable, when you have to manipulate the outcome before converting into 8-bits. But the scanner is perfectly able to send in 8-bit mode. It can also send in INQ_IMG_FMT_OKLINE (pie.c) mode which is not indexed and which I could not detect in any of my logs. > Changing the "scan mode" option of Cyberview ("Normal" or "Quality") results > in > a change in the required-speed byte of the MODE SELECT data. There is not much > information about this setting from PIE/Reflecta, and I also do not know what > speed may have to do with it. > That kept me busy last weekend. The quality setting also seems to influence what I call calibration mode. As you see in my rough outline above, there a scans during which reading the 45 lines is ommited and then they have to be ommitted. It appeares that real calibration is done after startup or whenever Quality is involved in the current or previous scans. > Yours - Jan > > If you wish to start toying around with your Reflecta scanner under SANE and need some help setting up a build system, let me know. I mostly work under Ubuntu 10.10. Regards Michael
