[Image-SIG] [ANN] Sane frontend, based on Python/PIL/PyGTK

[abel deuring]

Fredrik Lundh wrote:

>>I have started work on Eikazo, a new Sane frontend
>>(http://eikazo.berlios.de). It focuses on "mass scans", especially
>>with ADF scanners -- it is not intended to compete with XSane or
>>Kooka with their quite elaborate functions.
>>
>>Some Eikazo features:
> 
> cool!

Thanks :)

> 
> is the updated sane module in the PIL directory the latest and greatest? 
>   should I simply grab a copy of that for PIL 1.1.6 ?

Uhhh, no ;) There is some newer stuff available (attached to this
mail) While the version packed with Eikazo has better threading
support (very useful for Eikazo ;), I've worked meanwhile on another
patch for _sane.c, but this patch may need some discussion.

The changes are related to Sane integer and fixed number options
that have more than one element (i.e., that are arrays of numbers;
the most important usage are gamma curves implemented in a scanner's
firmware). Without this patch, such options are not readable (except
for the first array element) or settable by PIL's Sane module.

I made two changes:

1. Sane "array options" are now returned as lists of Python
   integers resp. floats. If such an option is set, any Python
   sequence type can be passed as the option's value (provided of
   course that is has the correct length).

2. the length of such an "array option" is given in the Sane API
   (http://www.sane-project.org/html/doc011.html) by the field
   'size' of struct SANE_Option_Descriptor. The data of this struct
   is mapped by SaneDev_get_options in _sane.c to an element of a
   Python tuple.

   SANE_Option_Descriptor.size gives the length of the data array in
   _bytes_, i.e., not the number of array elements. The "offical
   Sane way" to get the number of array elements in C is to
   calculate SANE_Option_Descriptor.size/sizeof(SANE_Word) -- but
   this division is not present in the current "offical" versions of
   the Python Sane module. Instead, the length in bytes is simply
   passed to the caller of SaneDev_get_options.

   The attached version of _sane.c has this division, making it
   easier and more reliable to get the "real" array length in
   Python. Needing to divide the size value by the "magic constant"
   4 in Python is IMHO a bit strange ;) Moreover, I am not sure, if
   sizeof(SANE_Word) is 4 or 8 on 64 bit platforms...

   On the other hand, this is an slight incompatibility to older
   versions.

   I don't believe that the size of a Sane option has been used so
   far very much in real application, because "array options" were
   not useable anyway, so the nummber of affected applications
   should be close to zero -- but this is a guess: I don't know
   every application that uses PIL and PIL's Sane module ;) On the
   other hand, one can also detect the array size in Python from the
   length of the list returned by SaneDev_get_option in the new
   version of _sane.c, so there is no urgent need for the division
   by sizeof(SANE_Word) -- it may just be more convenient in some
   cases.

To sum up possible problems:

1. A very naive application that simply tries to access every
scanner option of type SANE_Int or SANE_Fixed without checking its
length will probably break. On the other hand, an application that
simply works with the first element of an array instead of the
entire array needs to be fixed anyway.

2. The change in SaneDev_get_options -- the division
SANE_Option_Descriptor.size/sizeof(SANE_Word) -- may break
applications that make this calculation for themselves in order to
avoid to access (up to now useless) array options.

Any comments, especially on the second change/problem?

Abel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _sane.c
Type: text/x-csrc
Size: 42355 bytes
Desc: not available
Url : http://mail.python.org/pipermail/image-sig/attachments/20060930/9e2b12a0/attachment-0001.c