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