[Image-SIG] [ANN] Sane frontend, based on Python/PIL/PyGTK
adeuring at gmx.net
Sat Sep 30 20:54:48 CEST 2006
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:
> 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
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
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 42355 bytes
Desc: not available
Url : http://mail.python.org/pipermail/image-sig/attachments/20060930/9e2b12a0/attachment-0001.c
More information about the Image-SIG