Omer Zak wrote:
>Did anyone actually deal with developing an C/C++ extension library for
>Python, which deals with numarray arrays; and interfacing it to Python
>scripts using swig?
>
>
Not exactly. I seem to recall writing some python C-API module accepting
input from Numeric array (I don't know if internal representation of
numarray is the same as for numeric, but swig was not involved).
>My motivation to use C is to optimize the most time-consuming
>operations.
>
>My problem is to convert, at the shortest possible time, few arrays of
>float values into an array of RGB pixel colors according to some
>complicated rules.
>
>The current pure Python full processing flow is as follows:
>
>1. Arithmetic and function operations on the values of some
>numarray.array() variables.
>2. Given the above variables, building a string of bytes, which are RGB
>values of pixels.
>3. Conversion of the string into Image using Image.fromstring() from the
>Image module.
>4. Conversion from Image into format, which can be drawn on Tk.Canvas
>using ImageTk.PhotoImage().
>5. Drawing the PhotoImage into canvas.
>
>Step (4) above ought to be redundant. Is there any way to directly
>create an ImageTk.PhotoImage() instance from a string (using C/C++ magic
>is OK)?
>
>
I did do something like that (actually just extended someone else's
code). It was severel years ago (but I recently saw people still using
it) - I'm not sure I remember the details right, and it's using some
in-house libraries (so might be easier to rewrite than extract the
relevant bits):
We wrote a simple C function (python C-API module) which converts data
from our internal type (not a PIL Image, but has similiar functionality
in this context) into something that Tk can handle : an image (I think
it was bmp or similiar format) encoded into a python string.
Basicly all you have to do is pack the bits and pad the lines to
complete bytes (new lines must start at byte boundary). There might have
also been an issue with line order (top to bottom vs. bottom to top) -
I'm not sure.
My contribution was resolving endianity and 32/64 bitness issues (the
input was stored in words, and original code was for non-x86 machine),
some bugfixing, and support for Robin-wrapped input (Robin was in-house
and beta project at the time) .
Please let me know if you find out more related info.
Amit
