[sane-devel] Reflecta ProScan / Crystalscan 7200 PIE film scanner update

[Michael Rickmann]

Hi Jan, hi Klaus,

last weekend came back from vacation without internet and there will be 
a similar period starting next week.

Am 10.09.2012 21:01, schrieb Vleeshouwers, J.M.:
> Hi Michael,
>
> I tested your modified Pie backend this weekend. I had to change one line to get it working. My scanner takes about 10 seconds to get ready after it decides to collect shading data after all. So in pie_usb_calibrate() I changed line 3307 to:
> status = pie_usb_wait_scanner (scanner, 30);
> (30 to be very safe) I also changed the polling frequency of pie_usb_wait_scanner() from 16 times per second to just 1 time per second. The windows driver only polls every 1.5 second. I did not check if this was essential, though.

I am glad it worked for you.

> With this change scanimage -L, -A and -T all work. And although I did not expect it, /tmp contains the scanned and cleaned image and a couple of auxiliary files. I'm impressed, the scratch/dust removal works very well!.

Most of my tests were with xsane. These files are written if the debug 
level is >= DBG_image. I needed it to control the dust removal. Well, I 
am more experienced in manipulating images than in obtaining them. When 
we have reached a common basis I will implement something to produce 
nice looking images from generic color negative film. The xsane options 
for that are rather primitive.

> While you are thinking about the proposal to create a separate backend for the Reflecta scanners, I got two more detailed questions for you:
> 1. When doing shading correction, your routine only corrects 2-byte values >4096 and 1-byte values >16. It looks like an efficiency issue, right? How much faster is it?
I can hardly remember. I think I had a look at the outcome of the rather 
simple algorithm and found that at low light intensities the original 
values were looking better than the corrected ones, possibly a rouding 
issue.
> 2. I did not yet study the dust/scratch removal functions. What seems critical me is how much memory they use, knowing that the Windows driver gets into memory trouble at high resolutions. Do these functions allow processing the data stream from scanner to frontend with limited buffering in between?
These routines rely on a whole image. Currently, they are optimized for 
speed. So I hold 4 color planes (~130 MB at 16 bit and 3600 dpi) in 
memory, in addition what I need to work with the infrared channel and 
the final adaptation of the cleaned pixels. I have not messured but I 
guess that the maximum may well be upto 300 MB. The routines work on one 
color plane at a time and the RGB assembly of the cleaned images also 
takes ~260 MB. I guess, in the end we might strip it down to half 
sacrificing speed, by storing the R, G, B color planes in files until 
they are needed, using short ints instead of ints and using a separate 
thread which immediately pipes the assembled RGB to sane_read.
> Yours,
>
> Jan
>
> ________________________________________
> From: Klaus Kaempf [kkaempf at suse.de]
> Sent: Monday, September 10, 2012 3:09 PM
> To: Michael Rickmann
> Cc:sane-devel at lists.alioth.debian.org; Vleeshouwers, J.M.
> Subject: Re: [sane-devel] Reflecta ProScan / Crystalscan 7200 PIE film scanner update
>
> Michael,
>
> thanks a lot for posting your changes !
>
> * Michael Rickmann<mrickma at gwdg.de>  [Aug 21. 2012 22:28]:
>> Now my questions:
>> Would code like the one in the patch be acceptable in SANE?
>> Would a separate backend be preferable to patching pie?
> Looking at the amount of changes required to properly support USB PIE
> devices and the high risk to break SCSI PIE devices, I'm meanwhile all
> for a separate backend.
Agreed, especially when you think about maintaining it in the long run. 
Let us call it reflecta at the moment as the naming in Jan's code seems 
to suggest it. Regard my pie patch as a study what can and should be done.
> Regards,
>
> Klaus
> --
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
I will try to answer some of the questions which have arisen while I was 
unresponsive in a different thread.
Yours
Michael