[sane-devel] Reflecta ProScan 7200

Sun May 29 21:48:02 UTC 2011

Hi Jan,
let me shortly describe what I have done in between, mostly programming. 
You find my latest files at 
http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/status-290511/ .
1) Reorganized code to allow for different but related scanner models 
under the same USB id.
2) Calibration not perfect yet but proof of concept done.
3) Shading correction in software works.
Ad 1): I introduced a structure PIE_USB_Model which will contain 
everything to distinguish between different PIE SF Scanner variants. 
When attaching a scanner I check for INQUIRY bit 0x74 and set the 
pointer "model" in the struct Pie_Device to a static definiton of our 
scanners.
Ad 2): I have continued to model the dependency of illumination from 
exposure time and gain for my scanner and come to some preliminary 
calibration functions pie_usb_calicalc_hiqual and 
pie_usb_calicalc_normal in pie_usb.c which allow me to acquire 
approximately grey images of a desired brightness from scans without 
slide, see images under above URL. For quality mode alone I would have 
to provide one double constant. For quality and normal modes it has 
become six unfortunately.
Ad 3): See the images just mentioned. As you have already guessed the 
answer to the COPY command seems to tell about the sensor elements used 
for the coming scan. So it is rather easy to use them as a lookup table 
into the vector of averaged calibration lines and then do a simple 
muldiv for each scanned pixel (see pie_usb_correct_shading).
If you have a chance to try my new files and I have guessed correctly 
your scanner should now advertise as PIE/Reflecta CrystalScan 7200 in 
answer to scanimage -L. We may even get around the difference in MODE 
SELECT byte 9 which has stalled your scanner so far. I tried to provide 
for it (see crystalscan_7200_model in pie_usb.c).

Am 26.05.2011 21:36, schrieb Vleeshouwers, J.M.:
> Hi Michael,
>
> That took me quite a while to think through, I'm stll not ready with
> everything yet. I think we need some kind of a document that accumulates all
> we have come to know. Maybe we should also try to agree on the names we use.
> I'm trying to compose it, but: not ready yet...
>
To have a document like that is needed. We may fail and somebody else 
has to profit from our attempts and carry on. The PIE/Reflecta scanners 
seem to be among the last film scanners being still actively produced, 
Plustek OpticFilm scanners competing (source www.filmscanner.info, 
German only).
> What surprises me is the difference you discovered. I attach my INQUIRY
> response so you can check if there are more differences except for byte 74
> (which equals 0x30 for the Crystalscan scanner). I would not expect large
> differences. Perhaps it is only a small change in the use of bit 3 in MODE
> SELECT byte 9 ("required speed").
Our scanners are somewhat different, see attached analysis of the 
INQUIRY answers. In summary:
Pro / Crystal Scan:
3600 / 7200 dec : get_inquiry_max_x_res
3600 / 7200 dec : get_inquiry_max_y_res
5340 / 10680 dec : get_inquiry_fb_max_scan_width
3444 / 6888 dec : get_inquiry_fb_max_scan_length
31 2E 30 31 / 31 2e 30 35 : 1.01 / 1.05 get_inquiry_halftones and following
36 / 30 : get_inquiry_model, added by me for byte 0x74
PIE.2009/09/23.16:30PM / PIE.2010/03/09.15:30PM : byte 0x7e and following
In your USB snoops I have seen no indication that your scanner can do 
7200 dpi. The calibration lines seem to consist of 5340 2-byte values 
(same as mine), enough for 37,6 mm at 3600 dpi, and also in the PARAM 
answers of your scanner there was no scan wider than 4884. Is my 
assumption right that your scanner fakes the 7200 dpi? Then we will have 
to override those INQUIRY values.
To me the "halftone" difference looks more like a difference in ASCII. I 
am almost sure that my scanner can not do half tones.
Let us use byte 0x74 to distinguish between our scanners.
You have the newer EEPROM but the same individual signed it off.

> If I send 0x02 (instead of 0x0a) to the scanner for quality mode, COPY gives
> an error, and REQUEST SENS gives 70 0005 000000000600000000 2000 = ILLEGAL
> REQUEST, INVALID command OPERATION CODE.
> Would it be worthwhile to check for differences in more detail, for example
> in the startup sequence?
I would recommend trial and error. As we can distinguish between the 
scanners send the appropriate.
> I think it's probably best to continue focussing on the SCSI-DC command.
> It seems logical to have exposure time, gain and offset for the R, G and B
> channels, and for "quality" mode your experiments show where they are in the
> 23-byte sent by the DC-command. But the "normal"-mode results are strange.
> You are right about the very dark scans I get (the raw data, Cyberview
> corrects for this). But it is strange that "normal" mode seems to do away
> with all pixel values in the lower half of the dynamic range, and expands
> the upper half (by a factor 2). That is what seems to be happening in
> "normal" mode, isn't it?
What I know for shure is that I was running into zero illumination for 
red at gains below 0x2f. Perhaps I did a mistake with one of the other 
still vague parameters. Currently, I work above that range while 
modelling for normal mode. Now offsets are very handy but do not have to 
be negative.
> We should check if we are missing context. Could it be that some of the
> unidentified 0xDC-information sets a shadow-highlight range of 50% to 100%?
> Might "normal" mode work by simply setting this range? Maybe the
> DC-information is interpreted by the scanner depending on the modes
> ("startup" mode (0x00) with very simple settings, a "normal" mode (0x08) with
> more parameters, and a "quality" mode (0x02/0x0a) with the most extensive
> parameter set.)
>
Yes, there are differences between modes and the constraints of the 
parameters but not what the actual meaning of parameters is concerned. 
PIE may switch between different resistors or switch on an offset which 
their chips provide but I guess they can not work around a few 
constants, e.g. the gain constant their chip uses. About the different 
modes, for my scanner Silverfast only uses the 0x02 one, i.e quality 
mode, as if it were the standard one and the other ones derived.
> Did you experiment with byte 15 (after the RGB-gains)? I notice 0x00 switches
> off the light during a scan, and non-0x00-values turn it on. I do not know
> if it is more than just switch on/off, but if we can specify the light
> intensity, we have an extra parameter to consider.
>
I did experiment, but found no real differences. Silverfast sometimes 
sets the next byte to 3 or 5 and then becomes awfully slow. So my 
current assumption about those unidentified 3 bytes in the back of the 
dc command is that they may determine some motor settings.
> Did you find a relationship of the exposure time specified in the INQUIRY
> reponse (min 100 max 2500) to the range you find? I do not see a factor 25
> between min and max?
>
No. I think we are dealing with different levels of complexity. On one 
hand the standard SCSI commands transmit rather high level and derived 
things, on the other hand there are the custom commands where really 
basic parameters seem to play a role.
> The (almost) exponential gain curves look like ones I found in datasheets
> (e.g.http://focus.ti.com/general/docs/lit/getliterature.tsp?
> genericPartNumber=vsp3100&fileType=pdf). Having an analytical description is
> nice, but not absolutely required; a look-up table for the relationship
> between the gain parameter value and the actual gain will also work. This
> table can be derived from your experiments, I'll describe how in the reference
> document.
>
Agreed, lookup tables are a possibility. But they may become a bit 
extensive if you have more than one independant variable, and we have 
got already two, exposure time and gain. We may get a third one, lamp - 
see your question about "byte 15 (after the RGB-gains)". In Silverfast I 
discovered a not greyed out option about lamp intensity which I have not 
snooped yet. We will see whether a lookup table or an awful floating 
point expression is easier to program.
> I have made a small program to communicate with the scanner outside of
> SANE, because I found I sometimes needed some more flexibility. I intend
> to use it for documenting my experiments as well, so I'm thinking of adding
> a facility to run the experiments based on a text script. If I see what
> is still asking for an explanantion, this effort may be worthwhile.
>
> Yours,
>
> Jan
> ________________________________________
>
>    
I got my film scanner as a present last Christmas, it is real fun which 
will well last over next Christmas.
Regards
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inqpro.txt.gz
Type: application/x-gzip
Size: 619 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110529/f45b685e/attachment.bin>