great news with regards to OpenCV support...

[Chris Colbert]

On Thu, Oct 8, 2009 at 11:38 PM, Damian Eads <eads at soe.ucsc.edu> wrote:
>
> 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.
>

That's how i've been going about it so far, but that obviously incurs
an overhead of determining, exactly if and what to return.

>> - 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.
>
 this is leading me to think it would be easiest to just have a
general validator that ensures each array conforms to a common set of
requirements

>>  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.
>
OpenCV cant handle 4D arrays. But it can handle 3D arrays with 4
channels (i.e. RGBA)
These errors can be caught in a validator.

>> 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.
>

the opencv calls are being made in a wrapper, and the function has a
reference to the array until it returns.

> 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
>