[sane-devel] Reflecta ProScan 7200

[Michael Rickmann]

Hi Jan,

Am 24.04.2011 00:58, schrieb Vleeshouwers, J.M.:
> Hi Michael,
>
> A short update on a couple of settings (mode normal/quality, auto-exposure, auto-gamma, and ICE).
> For details see: http://www.stadspartijeindhoven.nl/jv/SettingsAnalysis.ods I'm not completely ready with all settings yet, but If you
> have suggestions for additional tests, let me know.
Thanks a lot, I am constantly looking up things in your tables instead 
of doing test scans under Windows. I have been busy teaching the pie 
backend 16-bit colours and larger read sizes than a single line. That 
kept me busy, so I have not done much progress with regard to the 
interpretation of snoops. But from the practical point of view, I wonder 
whether GAMMA can be sent to the scanner or has to be handled by 
software - my native scans are far to dark - it nags - and a preset 
GAMMA of 2.2 as Windows-Silverfast uses would be just ideal. So far I 
have seen no indication that the Win progs send any related information 
over USB. And GAMMA as sent by the pie backend is not accepted by my 
scanner: IO-error.

> Setting mode to "quality" results in a recalibration before each scan, whereas in "normal" mode the scanner
> only calibrates when the scanner is switched on. Apart from that, a bit is set in MODE SELECT byte 7. I do not notice
> other settings changes.
Byte 7? From looking at your tables and what I have experienced it must 
be the "required speed" byte. With that one I only use values 0, 2, 8 
mimicking the behaviour you just described. For me it is more a mode 
byte than a speed one. Bit 1 (the 2) means quality and bit 3 (the 8) 
omit calibration. It would be interesting what 0x0a does. When switching 
from 2 to 8 in two consecutive scans I get an error which resolves to 
"calibration disable not granted" in a "request sense" query.

> Setting auto-exposure results in a double scan when asking a preview. The first scan probably assesses the appropriate
> exposure settings, and the second is the actual preview. The effect is noticable in the preview. Perhaps if I wouldn't
> have asked a preview, this additional scan would have happened before the actual scan, but I didn't check. Remarkably,
> the SCSI 0A command for SET EXPOSURE TIME does not change. The only output command with new data in between the exposure
> scan and the preview scan is a SCSI D7. Apparently exposure related settings are part of what's being sent here.
It somehow makes sense if exposure settings were sent, see below: DC 
command.

> Setting auto-gamma does not lead to any changes at all. Does that make any sense?
>
> When setting ICE, in MODE SELECT byte 4 an additional bit is set, which results in sending RGBI-data to Cyberview instead
> of just RGB. The infrared-channnel can be converted into a monochrome picture which shows the dust and scratches,
> and some vague contours of the original slide. I did not yet check if the RGB-data is original or has the scratches
> removed.
>
> The settings do not appear to influence these SCSI-commands:
> - SCSI 08 (READ CALIBRATION INFORMATION)
> - SCSI 0A (WRITE - SET SCAN FRAME)
> - SCSI 0A (WRITE - SET EXPOSURE TIME)
> - SCSI 0A (WRITE - SET HIGHLIGHT SHADOW)
> - SCSI 0A (WRITE 17, function unknown)
> - SCSI 0A (WRITE - REQUEST CALIBRATION INFORMATION)
> - SCSI 18 (COPY)
> - SCSI 1B (SCAN)
> - SCSI D2 (? RELEASE)
> The remaining commands are infuenced:
> - SCSI 15 (MODE SELECT)
> - SCSI 0F (READ SCAN PARAMETERS)
> - SCSI D7 (? READ CUSTOM DATA)
> - SCSI DC (? WRITE CUSTOM DATA)
>
> About the interpretation of DC and D7 (and probably bytes 12 and 13 of SCSI 0F as well):
>
> No, I did not see any larger amounts of data written to the scanner. I suppose only very basic calibration parameters
> are being sent, nothing else. Is it possible that the calibration scan data (1+13+31 lines) are used by Cyberview to do
> shading correction?
> Why do you think the first six DC-bytes are 12-bit RGB-values? The most-significant 4 bits are used sometimes, and apart
> from that there is some unbalance I cannot explain. If interpreted as 2-byte integers, most of the time the three values
> are around 3000. But sometimes they double or even triple, and in a couple of cases the first value is the only one that
> deviates. I don't see any logical reasons for that. Might these 2-byte values represent floating point numbers? They are
> not IEEE half-precision values, I checked that. Would there be any use for floats?
I checked again, bytes 0 - 5 are 16-bit values. I must have done a 
mistake to realize a wrap after 12 bits. Have a look at my current 
definition of the DC-command (first 6 bytes are header):
typedef struct PIE_USB_Calibration_Send
{
   unsigned char scsi_cmd[6];
   uint16_t red_texp;
   uint16_t green_texp;
   uint16_t blue_texp;
   unsigned char copy_1[6];
   unsigned char red_gain;
   unsigned char green_gain;
   unsigned char blue_gain;
   unsigned char some_time[3];
   unsigned char copy_2[5];
} __attribute__ ((__packed__)) PIE_USB_Calibration_Send;

The copy blocks are from the preceding D7 read. Bytes 0 - 5 do not only 
change the color but also the sound of the scanner - higher values to 
deeper tones. It may be that the SET EXPOSURE TIME was shifted here. It 
would make sense to change these values for "auto-exposure" as you might 
have seen in your test runs above. In normal mode bytes 0 - 5 are 
limited to 12 bits and the gain values are close to 3f (6 bits, close to 
maximum) which would mean fastest speed. In quality mode bytes 0 - 5 are 
16 bit wide but the gain values are around 0x26. I think that you can 
find the quality gain values also in the preceding D7 read, only one 
less (-1) at position 72 (first position is 0).

> The D7-data returned by the scanner show something similar in bytes 6-11. If they refer to RGB respectively, what could
> be the reason that the first value is 1.5 times the 2nd and 3rd?
> When interpreted as 2-byte integers, bytes 0-5 have three values which resemble numbers I found in discussions about
> 16-bit CCD saturation. These values are updated after the scanner has sent out calibration data (1+13+31 lines).
> I can imagine the scanner presents this information for calibration purposes, right?
Right! When I average RGB values from the 13 read calibration lines and 
apply the equation contained in pie.c's pie_perform_cal with fullscale = 
0xf000, I come into the range of bytes 0 - 5, but for quality mode only.

> To be continued, I suppose.
>
> Jan
>
Yes, it seems as it were a project which is ready to be submitted to 
SANE 2.x when RGBI will be hopefully allowed. That will be my next task 
to teach the pie backend RGBI and to discard the "I" in a SANE 1.x 
compatible way. Perhaps we can clean part of the dust while waiting for 
USB data. That seems feasable upto a vertical filter step.

Regards
Michael