opencv crashes as I import it

[GoogleCodeExporter]

What steps will reproduce the problem?
1. write "import opencv" in the python shell
2.
3.

What is the expected output? What do you see instead?
expected: nothing
What I see:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Python/2.5/site-packages/opencv/__init__.py", line 19, in
<module>
    from opencv.cv import *
  File "/Library/Python/2.5/site-packages/opencv/cv.py", line 2562, in <module>
    ('desc', CvMat_r, 1), # CvMat* desc
  File "/Library/Python/2.5/site-packages/opencv/cxcore.py", line 114, in cfunc
    return CFUNCTYPE(result, *atypes)((name, dll), tuple(aflags))
AttributeError: dlsym(0x324b50, cvCreateFeatureTree): symbol not found

What version of the product are you using? On what operating system?
most current (trunk checkout, revision 202)
OS X Leopard 10.5.6

Please provide any additional information below.

Original issue reported on code.google.com by candersonmiller on 30 Jan 2009 at 6:12

[GoogleCodeExporter]

This error:

AttributeError: dlsym(0x324b50, cvCreateFeatureTree): symbol not found

means that function cvCreateFeatureTree() is not found in the detected 
'libcv.dylib'
file. Can you check for me if the function cvCreateFeatureTree() was compiled 
and is
working well in your the OpenCV installation?

Original comment by pmtri80@gmail.com on 30 Jan 2009 at 7:52

[GoogleCodeExporter]

I'm on the latest stable revision tag of openCV
Revision 1569.

No showstopping errors through cmake, make, or make install.

libcv.dylib is definitely installed.

How can I test if libcv.dylib is working well?

Original comment by candersonmiller on 30 Jan 2009 at 8:06

[GoogleCodeExporter]

I don't have a problem on an OS X 10.4/Tiger system with r1454 from late 
December,
but can try bumping up to the latest trunk revision when I get a chance later 
this
evening.

You might try running "nm libcv.dylib | grep _cvCreateFeatureTree" on your 
system and
seeing if the symbol is present.

I'd probably also try printing opencv._cvDLL just to verify that it's loading 
the
copy of libcv.dylib that you expect.

Original comment by db3l....@gmail.com on 31 Jan 2009 at 1:02

[GoogleCodeExporter]

"nm /usr/local/lib/libcv.dylib | grep _cvCreateFeatureTree"  returns no results
 - in what environment would I print opencv._cvDLL?

Original comment by candersonmiller on 31 Jan 2009 at 1:32

[GoogleCodeExporter]

From comment 4, it looks like the cvCreateFeatureTree symbol does not exist 
from your
current libcv.dylib file. One way to test if this function is available in your
installation is to execute a simple piece of C code below and see if there is 
any
compilation error.

#include "cv.h"

int main(void)
{
    CvMat* mat = cvCreateMat(10, 20, CV_64FC1);
    CvFeatureTree *tree = cvCreateFeatureTree(mat);
    return 0;
}

Original comment by pmtri80@gmail.com on 31 Jan 2009 at 3:26

[GoogleCodeExporter]

test.c:6: error: ‘CvFeatureTree’ undeclared (first use in this function)

So - it doesn't - what do I do now?

Original comment by candersonmiller on 31 Jan 2009 at 4:21

[GoogleCodeExporter]

I've found out that since r1475, function cvCreateFeatureTree has been renamed 
to
cvCreateKDTree. It looks like there's been some development in the OpenCV's main
trunk now. Perhaps you might want to wait for them to stabilize their code 
first.

Best regards,

Minh-Tri

Original comment by pmtri80@gmail.com on 31 Jan 2009 at 6:04

[GoogleCodeExporter]

okay - I just checked out and installed r1475 of the opencv library - and I'm 
getting all the same errors.  What 
should I do if I want to get up and running soon?

Original comment by candersonmiller on 31 Jan 2009 at 6:37

[GoogleCodeExporter]

If you don't mind, can you try r1474 instead? r1475 is where the change was 
made.

Unfortunately, I do not have a Mac OS to test so at best I can only speculate.

Best regards,

Minh-Tri

Original comment by pmtri80@gmail.com on 31 Jan 2009 at 9:10

[GoogleCodeExporter]

I just finished building against the latest trunk revision (1569) on my 10.4 
system
(took a bit longer than I expected since apparently the configure approach 
doesn't
handle building the local lapack library, so I needed to set up cmake).

It looks like this is the only incompatibility with the wrapper - at least that 
I can
detect so far.  So canderson, unless you need the function you can basically 
just
comment out the code that tries to wrap it in your copy of the ctypes-opencv 
package
if you want to avoid the error.  Or you can locally apply the attached patch.

I'm attaching a proposed patch that wraps either function, calling it by the 
later
cvCreateKDTree name.  I've left an alias in for the older cvCreateFeatureTree, 
but it
might be something not worth including, since anyone developing against 1.1 is
already going against a moving target anyway, so maybe better to just track the 
trunk.

The patch also corrects CvFeatureTree to only release when appropriate, and to 
have
_fields_ so repr() works.  And lastly, I noticed that cvReleaseFeatureTree was
actually wrapping the old cvCreateFeatureTree, so adjusted that.

I don't actually know what sort of matrix contents the function wants, but with 
the
patch the wrapper works with the trunk OpenCV on OSX, as well as 1.0 and 
1.1pre1 on
Windows, inasmuch as I can call it with a random 32x32 vector.

-- David

PS: There are some other _Structure subclasses that also don't define _fields_, 
and a
handful with _fields_ of [] so I'm thinking that perhaps _Structure should have 
an
empty _fields_ = [] definition to at least keep the other structures repr()able
and/or avoid their need to define an empty list if they have no accessible 
fields?

Original comment by db3l....@gmail.com on 31 Jan 2009 at 9:49

Attachments:

• feature.diff

[GoogleCodeExporter]

Thanks David for your great effort in making ctypes-opencv compatible with 
r1569. I
have taken your advice and added "_field_ = []" to _Structure. However, I'd 
rather
just support the official releases of OpenCV. I do not have time to follow every
OpenCV's trunk revision, not to mention that we need to identify which revision 
is
stable enough for supporting.

Canderson, please let us know if your problem is still not resolved. Otherwise, 
I'd
like to close this issue.

Minh-Tri

Original comment by pmtri80@gmail.com on 2 Feb 2009 at 1:31

[GoogleCodeExporter]

First, no problem with this from me - at worst this is a patch that can be 
applied
locally by someone using the trunk until the wrapper is officially updated.

I am curious though - do you consider 1.1pre1 a full release?  I saw it just as 
an
early snapshot/pre-release/release candidate for what will eventually be 1.1, so
while it's interesting in terms of having some binaries at that specific 
revision,
and worth testing against as a discrete release, it seems to me that someone 
using
1.1 at the moment is just as likely to be tracking the trunk as it evolves since
1.1pre1 went out with some known issues.  

I'm certainly not advocating daily tests against the trunk, but if we happen to 
get
lucky and someone catches something that we can cover before it gets formalized 
as
1.1pre2 or 1.1, so support could already be in the wrapper, all the better.  I
suppose there's some risk the change will be reverted, but the wrappers are 
still in
development too.

Oh, independent of the above you may want to cherry pick the portion of the 
patch
that corrects the wrapper for _cvReleaseFeatureTree, since right now it calls
cvCreateFeatureTree.  The addition of _owner to CvFeatureTree may be useful too
(though less of a strong argument) since if you happen to create that structure
directly at some point, you'll crash when you exit Python and it tries to 
release itself.

Original comment by db3l.em...@gmail.com on 2 Feb 2009 at 4:00

[GoogleCodeExporter]

Oh. Sorry I have missed out your reply. I have some points to discuss with but 
at the
moment I don't have time for ctypes_opencv. I have some matters in real life to 
take
care of. I'll answer you asap, but probably not until March 10. I apologize.

Best regards,

Minh-Tri

Original comment by pmtri80@gmail.com on 24 Feb 2009 at 6:48

[GoogleCodeExporter]

I just finished my oral defence last Friday. Let's continue our discussion. I
understand there are some known issues with 1.1pre1. Also, I'm aware that there 
are
some significant changes in OpenCV's interface, which may break our 
ctypes-opencv in
the future. I'm ok with supporting the trunk. We need to nail down which 
revision to
support. Is there any way to detect which revision the user is using? Otherwise,
perhaps we can create a branch to support the trunk. 

Meanwhile, I'll incorporate all the recent patches and release a bug fix 
version.

Best regards,

Minh-Tri

Original comment by pmtri80@gmail.com on 5 Apr 2009 at 6:41

[GoogleCodeExporter]

In light of recent OpenCV development, I guess it is safe to wait until they 
release
their new version, hopefully in this June, before we start wrapping new 
functions.

Original comment by pmtri80@gmail.com on 17 Jun 2009 at 3:09

• Changed state: Fixed