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

[Michael Rickmann]

Hi Jan,
a late answer to your questions, just to point out what is not yet 
obsolete.

Am 23.08.2012 20:02, schrieb Vleeshouwers, J.M.:
> Hi Michael,
>
> Good to see you picked it up again!
>
> Regarding your 2nd question: I think we should create a separate 
> backend. I've got two reasons for that: 1) the patch makes the pie 
> backend a very large and complex unit, and 2) I don't want to have to 
> worry about breaking the existing pie functionality every time we 
> modify the usb part. I hope you and Klaus agree.
>
> I did some work on this track, although it is not complete. I took 
> your code (version fall 2011) apart and I am now slowly getting all 
> pieces to work again (in a way I understand). The major thing that 
> does not work yet is sane_read(). Your code is based on the 
> index-format, but I think the pixel-format should be much more 
> practical, since the SANE standard expects RGB pixels to be returned 
> from sane_read().
I see your point here: The indexed reading results in rather ugly code 
because the scanner does not deliver the R, G, B, I colored lines in any 
predictable order and one has to store components of several lines 
before one is complete. It seems that the amount of data which has to be 
buffered can be derived from the filterOffsets in the 
Reflecta_Scan_Parameters structure. If you do this in a separate thread 
complete lines can be written to a pipe from where they can be 
“sane_read”. If you wish to process whole images in software before they 
are read there is no need for a separate thread.
Nevertheless, I would like to stick to indexed reading. Arguments follow:
1) The Windows programs use it. None of the snoops I made contained 
image data in a different format than INQ_COLOR_FORMAT_INDEX.
2) I discovered reading in INQ_COLOR_FORMAT_LINE by accident because it 
was offered by the pie backend and was able to read RGB data. I was not 
able to read RGBI. I did not try very hard because there was the other 
Windows backed possibility. So work will have to be done here without 
being backed by snooping.
3) I suspect that the reordering of the R, G, B, I lines has to be done 
somewhere, either in the scanner or in the backend. Certainly the 
backend solution would be faster.
> I divided the code into four sections:
> a. Low-level functions which communicate with the device on a 
> byte-level. These implement the usb-wrapper but only handle 
> byte-arrays, no interpretation takes place here. This section is 
> complete and tested.
> b. Mid-level scanner functions for scanner commands, which take a 
> meaningful struct as an argument (such as mode_select() which takes a 
> 'struct Mode' as a parameter) and return a 'struct Status' which 
> includes sense data if an error occurs. These functions automatically 
> issue a REQUEST SENSE command if a command returns CHECK SENSE, and 
> repeat a command if the device is reports a busy state. No reason to 
> take care of this anymore at a higher level, which is practical. This 
> section is almost complete, and quite easy to extend. Klaus' device 
> has commands for moving to the next and previous slide, these are not 
> implemented (not yet).
I like this section very much, especially the internal use of 
SANE_STATUS_CHECK_CONDITION. This should be our code.
> c. Top-level auxiliary functions, e.g. for initialising options, 
> correcting shading, etc. A lot still missing.
> d. Top-level SANE interface functions. Missing sane_read() and 
> sane_get_parameters(), the rest implemented according to the procedure 
> of the Windows driver. Not much tested yet.
>
> I see you managed to find and implement dust/scratch removal 
> algorithms. That is very welcome! I hope we can get a positive answer 
> to your third question. It looks like you chose to implement this in 
> the backend, which is practical since it does not break the SANE 
> standard.  This might be the best solution for now.
> This makes our wishlist a bit smaller as far as I am concerned. Remains:
> - react to a button press (use scanbuttond daemon? it that the 
> solution we want?)
> - export infrared data (for other uses than dust/scratch removal; 
> maybe modify the scanimage frontend and stiff.c to allow RGBI TIFF 
> image files to be exported?)
>
> So how do we proceed?
> - We have got two pie-patched backends (Klaus' and yours) which I 
> assume should be merged
> - We have got a stand-alone backend in an incomplete state (see 
> attachment)
> We should decide on a common starting point. If we decide for a 
> separate backend, I would prefer the four-section structure. You and 
> Klaus are familiar with software development, at least more than I am, 
> so we should use that.
I guess I am the least professional of us three in this project spending 
most time on neurobiology. Ok, four sections plus a fifth one for 
processing the read images. Section c should contain task related 
routines to gain some fexibility and to keep the SANE interface routines 
readable.
>
> Yours,
>
> Jan
>
> -----Original Message-----
> From: Michael Rickmann [mailto:mrickma at gwdg.de]
> Sent: dinsdag 21 augustus 2012 22:27
> To: sane-devel at lists.alioth.debian.org; Vleeshouwers, J.M.
> Subject: Reflecta ProScan / Crystalscan 7200 PIE film scanner update
<--- snipp

Regards
Michael