great news with regards to OpenCV support...

[Damian Eads]

On Thu, Oct 8, 2009 at 2:18 PM, Chris Colbert <sccolbert at gmail.com> wrote:
>
> So my next question is: how much hand holding should I do on my end
> for the user?
>
> There are several things I would like to address here:
>
> - opencv makes extensive use of *out arguments, should we require the user to
>  preallocate their out array or should we make it for them and return it.
>  The latter option is more pythonic, but comes with a small overhead for
>  determining a proper return dtype

I think having out be None by default is best.

> - how much checking should I do on the input array. OpenCV images can accept
>  6 different dtypes.  If the user passes an incorrect dtype, should I
> raise an exception
>  or just let it fail with a KeyError during the dtype lookup?

An exception with a meaningful error message like "type unsupported"
is more useful to the user than a KeyError in an undocumented, local
variable data structure.

>  How much checking should I do on the array dimensions. We can use 2D
> or 3D arrays
>  with the third dimension equal to 2, 3, or 4. Should I check that
> the passed arrays conform to
>  this, or just let everything fail? Again, how much validation
> overhead should we allow

It's not clear to me how the best way to write to a 4D array. It's
probably best to throw an exception unless you can come up with a
clear use case for high dimensional arrays.

> On the technical side, I'm wondering if I should INCREF the numpy
> array when I pass it to OpenCV. If Python somehow gc'ed the array
> while OpenCV is working on it, that could be nasty.  The only way I
> see this happening is if I start releasing the GIL on opencv calls.
> This brings the advantage of performance during threading but will not
> at all be thread safe since I'm "borrowing" the numpy data pointer.

Will users call the OpenCV functions directly or do you have Python
wrappers? If your Python wrapper function keeps a reference to the
array throughout execution in C-space, you can probably avoid the
INCREF.

Damian

> On Thu, Oct 8, 2009 at 10:59 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>>
>> Fantastic! This is great news.
>>
>>
>> On Oct 8, 2009, at 3:37 PM, Chris Colbert wrote:
>>
>>> At least I think it is great!
>>>
>>> I've managed (with the help of the community) to get ctypes function
>>> pointers to play nice with cython.
>>>
>>> I've also re-implented the IplImage struct in cython and figured out
>>> how to populate the struct with numpy stride information and the numpy
>>> data pointer.
>>>
>>> This all means that we now have the ability to to call OpenCV
>>> functions with plain numpy arrays as arguments, and the array gets
>>> modified in place!. And since i'm using ctypes to grab the function
>>> handle, OpenCV is not required to be on the users machine during build
>>> time, but if and when  they install the opencv lib, they automagically
>>> work!
>>>
>>> I've a got a working (albeit ugly) example attached. You'll obviously
>>> need opencv installed if you want to test it.
>>>
>>> Just use PIL to open any image on your system then dump it into a
>>> numpy array then call testnumpy.test(arr) on that array.
>>>
>>> Dump the array back into a PIL image and call show() on it. Voila!
>>> your image has been guassianed blurred courtesy of OpenCV.
>>>
>>>
>>> So, now that I have the logistics of this figured out and I know it
>>> actually works, looks like I'll have plenty to implement during the
>>> upcoming sprint.
>>>
>>> Cheers!
>>>
>>> Chris
>>> <testnumpy.pyx>
>>
>>
>



-- 
-----------------------------------------------------
Damian Eads                           Ph.D. Candidate
University of California             Computer Science
1156 High Street         Machine Learning Lab, E2-489
Santa Cruz, CA 95064    http://www.soe.ucsc.edu/~eads