dionysio / ctypes-opencv Goto Github PK

The automatic memory management is a key feature of ctypes-opencv, but the
use of pointer() in the __del__ methods appears fragile during interpreter
shutdown.

I was getting a lot of stray exceptions during interactive experimentation
upon existing the interpreter, occurring within the IplImage.__del__
method.  Depending on the sequence of the removal of global objects (such
as modules), function dependencies of __del__ methods may no longer be met.
 While not my original problem case, assume the following two modules:

bad_parent.py:

    import bad

bad.py:

    import opencv as cv
    t = cv.cvCreateImage(cv.cvSize(320,240), 8, 3)

Then, under Python 2.5 (2.5.1 in the below example), running bad_parent.py
will generate an exception when t attempts to clean itself up:

> python bad_parent.py
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method IplImage.__del__ of
IplImage(nSize=112,ID=0,nChannels=3,alphaChannel=0,depth=8,colorModel='RGB',chan
nelSeq='BGR',dataOrder=0,origin=0,align=4,width=320,height=240,roi=<ctypes.LP_Ip
lROI
object at 0x00985E40>,maskROI=<ctypes.LP_IplImageobject at
0x00985E40>,imageID=None,tileInfo=<ctypes.LP_IplTileInfo object at
0x00985DF0>,imageSize=230400,widthStep=960,BorderMode=<opencv.cxcore.c_long_Arra
y_4
object at 0x00985DA0>,BorderConst=<opencv.cxcore.c_long_Array_4 object at
0x00985DA0>)> ignored

I tracked it down to the fact that pointer(IplImage) had never been called
during execution, so it had no cached pointer type.  In order to create a
new pointer type it tries to use_ctypes._Pointer(), but somewhere in that
process it runs into something that has probably been cleared already by
the interpreter.

Note that the issue is tricky - it only occurs with some module names and
import combinations since that affects when other modules are destroyed at
shutdown.  For example, calling bad.py "working.py" instead avoids the
error.  Also, just adding a call to pointer(IplImage) inside of bad.py
fixes things since the pointer type is then cached.  And finally python
2.6/3.0 seem to handle even the "bad" case, but I presume it's likely that
other configurations might tickle poor behavior in those versions.

Since such __del__ exceptions are ignored by the interpreter, they're
arguably unimportant, but depending on what is happening at object release
time it may be a problem as nothing past the exception point in __del__
runs.  So, for example, for CvVideoWriter it might result in not calling
cvReleaseVideoWriter which would leave a corrupted file.

Since all the destructor is trying to do is get a pointer-to-pointer to the
object being destroyed, I'd like to suggest skipping past pointer (which
has to create the pointer type), and just create a void * with the address
of the object needing to be released.  The attached patch (against trunk
r139) has that change.

Note that I've actually run into cases during an object's destructor where
globals from its own module were no longer available - so even referencing
names like addressof() or _cvReleaseImage might theoretically during
interpreter shutdown.  I haven't actually seen that yet, but if so, the
best way to work around that is to cache references to the objects needed
during destruction during instance construction so there's no dependence on
module level entities during destruction.

I do a lot of interactive experimentation on Windows and early on
implemented my own poor man's background window implementation so I didn't
have to keep calling cvWaitKey all the time, since OpenCV has no native
cvStartWindowThread implementation on Windows.

I decided to try packaging it up more neatly, and it's not too bad.  I've
attached two files.  The first (highgui_win32) is a module implementing the
highgui window-related functions that can defer their operation to a
background thread, if it's been created with the standard
cvStartWindowThread function.  Otherwise they just pass control to the
normal highgui wrappers.

The second is a patch to __init__ to load this module on Windows, in which
case its functions will overlay the originals in highgui, so on Windows it
transparently takes over and gives users a working cvStartWindowThread.

This form of the wrapper is a little new (as opposed to my grown-over-time
original version), so may have some rough edges, but it still works with my
stuff, and it only really becomes active if you create the thread. 
Existing demos run fine without doing so.

-- David

I was going to ask if the cvWaitKey return type could be reverted to a pure
int, but then realized that the standard wrappers also seem to return it as
a string, so figured compatibility was good.  Although it'll break some of
the demos in Python 3 which use common patterns like 
    cvWaitKey(10) >= 0 
since you can't compare strings and numbers in Python 3.

Anyway - there is a small issue with the current wrapping though, in that
under Linux/Gtk, the result of the C level cvWaitKey has shift/event
information in the upper 16 bits. So the '%c' conversion will fail, as in:

>>> cv.WaitKey(20000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/site-packages/opencv/highgui.py", line
224, in cvWaitKey
    return z if z <= 0 else '%c' %z
OverflowError: unsigned byte integer is greater than maximum

In the default wrappers, they are working in C so they just silently
truncate the value by assigning it to a char.  I'd probably suggest that we
use (z & 0xFF) or something similar to protect the current wrapper.

-- David

What steps will reproduce the problem?
1. use the function cvIplImageAsBitmap
2.
3.

What is the expected output? What do you see instead?
a bitmap. an error

What version of the product are you using? On what operating system?

0.7.3

Please provide any additional information below.
need to import cvConvertImage from HighGui.

What steps will reproduce the problem?
NA

What is the expected output? What do you see instead?
NA

What version of the product are you using? On what operating system?
ctypes-opencv-0.7.3.win32-py2.5.exe

Please provide any additional information below.
Moment m01 is lacking in définition of class CvMoments in cv.py.

From this test code:

"""
import datetime
import opencv

def bench_mat(i__size=1000, i__numpy=False):
    if not i__numpy:
        l__mat = opencv.cvCreateMat(i__size, i__size, opencv.CV_32FC1)
        for l__x in range(i__size):
            for l__y in range(i__size):
                l__mat[l__x, l__y] = 0.0
    else:
        l__mat = opencv.cvCreateMat(i__size, i__size, opencv.CV_32FC1)
        l__mat_numpy = l__mat.as_numpy_array()
        for l__x in range(i__size):
            for l__y in range(i__size):
                l__mat_numpy[l__x, l__y] = 0.0


if __name__ == '__main__':
    print 'benching mat'
    print datetime.datetime.now()
    bench_mat(1000, False)
    print datetime.datetime.now()
    print 'benching numpy'
    print datetime.datetime.now()
    bench_mat(1000, True)
    print datetime.datetime.now()
    print 'benching numpy'
"""

I get this result:


C:\tmp>python bench_cvmat.py
benching mat
2009-07-16 20:24:10.109000
2009-07-16 20:24:23.109000
benching numpy
2009-07-16 20:24:23.109000
2009-07-16 20:24:23.390000
benching numpy

C:\tmp>



Why is that ??? Why cvMat is performing much poorer than as numpy array ?
Is there something to correct this ?

The attached diff (against trunk @183) corrects a few issues with some
histogram related functions.

First, cvQueryHistValue_1D has an extra argument.

Second, the use of "hist.bins" in the cvQuery/GetHist* functions don't work
given the use of ByRefArg (through CvArr_r) and the declaration of CvArr. 
You get an OpenCV error about invalid array.

Although under the covers the bins member and the mat member of CvHistogram
both point to the same memory, taking the byref(bins) gives the address of
the pointer and not the value of the pointer.  Switching to using
"hist.bins.contents" cleans this up, but for that to avoid a ctypes error,
there needs to be a _fields_ member of CvArr, even if empty.

And third, even though the wrapper declaration permits None for the ranges
parameter to cvCreateHist, the ListPOINTER2 ctypes wrapper doesn't.  I
added a check for None there to permit it to pass through.

-- David

What steps will reproduce the problem?
1. Create and IPL image from any source img = ...
2. cvIplImageAsBitmap(img)


What is the expected output? What do you see instead?
you would expect it to return a wxBitmap instead you get this error:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python25\lib\threading.py", line 486, in __bootstrap_inner
    self.run()
  File "<string>", line 34, in run
  File "C:\Python25\lib\site-packages\opencv\interfaces.py", line 37, in
cvIplImageAsBitmap
    flags = CV_CVTIMG_SWAP_RB
NameError: global name 'CV_CVTIMG_SWAP_RB' is not defined

What version of the product are you using? On what operating system?
python 2.5, opencv 1.1prea, newest version of ctypes-opencv

Please provide any additional information below.


fix this by adding:   from opencv.highgui import *    to the top of the
interfaces.py module. 

One thing I've been finding inconvenient recently is the fact that two
(apparently) identical ctypes data types don't compare as equivalent. 
Thus, the current wrapper has the behavior that
"cvSize(5,10)==cvSize(5,10)" is False, whereas even in C comparing the
structures generated by those two constructors would compare true.  A lot
of it comes from the fact that in ctypes, even c_int(5)==c_int(5) is false.

At best it's inconvenient as you have to check the fields, but at worst it
can slip by, such as when I did a simple check during a loop to see if
cvGetSize on the supplied image was different than the prior frame and
ended up incurring a lot more overhead than needed, as I thought every
frame was different.

The attached patch attempts to remedy this by providing equivalence for
structure types based on their underlying fields, using the wrapped value
(e.g., 5 for c_int(5)) when available or for pointers, the address being
pointed to.  It also permits comparisons to hold true when comparing to a
native Python tuple, as long as that tuple can construct an equivalent object.

Demos all continue to run, although since they couldn't currently depend on
equivalence, I suppose that's not surprising.

What steps will reproduce the problem?
1. create a matrix with cvCreateMat
2. save the matrix with cvSave

What is the expected output? What do you see instead?

saved matrix file. I got following message:

Traceback (most recent call last):
  File "D:\workspace\Doonoon\gui\Doonoon_frame.py", line 257, in Calibrate
    cvSave( "object_pointS.xml", self.object_points )
ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type

What version of the product are you using? On what operating system?
I'm using ctypes-opencv 0.7.2, with OpenCV 1.0 DLLs on WindowsXP (SP3). 
I'm using Eclipse with PyDev extension. 

Please provide any additional information below.
I'm trying to calibrate my webcam using cvCalibrateCamera2(). It seems I 
got the resulting intrinsic matrix and distortion coeffs, I can't save 
those matrices into files. Then, I tried to cvSave right after the matrix 
was created like this:

    self.intrinsic_matrix  = cvCreateMat( 3, 3, CV_32FC1 )
    self.distortion_coeffs = cvCreateMat( 4, 1, CV_32FC1 )
    self.point_counts      = cvCreateMat( self.n_boards, 1, CV_32SC1 )
    self.image_points      = cvCreateMat( self.n_boards * self.board_n, 2, 
CV_32FC1 )
    self.object_points     = cvCreateMat( self.n_boards * self.board_n, 3, 
CV_32FC1 )
    self.successes = 0
    self.calibration_finished = False
    cvSave( "Intrinsics.xml", self.intrinsic_matrix )
    cvSave( "Distortion.xml", self.distortion_coeffs )

However, the result was the same: 

  File "D:\workspace\Doonoon\gui\Doonoon_frame.py", line 239, in 
init_matrices
    cvSave( "Intrinsics.xml", self.intrinsic_matrix )
ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type

Wow, this one took me an amazingly long time to track down relative to its
fix.  Bottom line is the cvThreshold return type has to be updated when
using OpenCV 1.1, but the impact of not doing so really surprised me.

I have been periodically testing against 1.1, and found recently that some
older calibration stuff I had no longer worked - the perspective transform
was bogus.  Turns out without having the right return code to cvThreshold
it somehow corrupts a later perspective transformation computation, but
I'll be darned if I know why.  However, this code:

------------------
import sys
from opencv import *

img = cvCreateImage((320,240), 8, 1)

if len(sys.argv) > 1:
    cvThreshold(img, img, threshold=200, max_value=255,
                threshold_type=CV_THRESH_BINARY)

arr = CvPoint2D32f * 4
src = arr(*[(15,23), (38,211), (275,211), (303,30)])
dst = arr(*[(0,0),   (0,240),  (320,240), (320,0)])
p_mat = cvCreateMat(3, 3, CV_32F)

cvGetPerspectiveTransform(src, dst, p_mat)

for i in range(3):
    for j in range(3):
        print '  ', cvGetReal2D(p_mat, i, j),
    print
-------------------

produces the following results (with/without cvThreshold, OpenCV 1.0 and 1.1):

> python perspective.py
   1.0484623909    -0.128269329667    -12.7767400742
   -0.0249321386218    1.0257794857    -23.2189445496
   -0.000103883910924    -0.000923765415791    1.0
> python perspective.py foo
   1.0484623909    -0.128269329667    -12.7767400742
   -0.0249321386218    1.0257794857    -23.2189445496
   -0.000103883910924    -0.000923765415791    1.0
> PATH=/pkg/opencv-1.1/bin:$PATH python perspective.py
   1.0484623909    -0.128269329667    -12.7767400742
   -0.0249321386218    1.0257794857    -23.2189445496
   -0.000103883910924    -0.000923765415791    1.0
> PATH=/pkg/opencv-1.1/bin:$PATH python perspective.py foo
   0.0    0.0    0.0
   0.0    0.0    0.0
   0.0    0.0    1.0

Geez.. 

Anyway, the attached patch just corrects the return code for 1.1.

Now if I could only figure out why Undistort2 is giving me different
results under 1.1 with the same camera matricies...

-- David

1.)How to specify in the program, the path of the image stored in a folder 
so as to displaying this image using cvShowImage function

2.)After writing a program, if i build it then 
I am getting the following error

fatal error LNK 1181:cannot open input file'cxcore[d].lib'

Kindly please reply for this

[deleted issue]

What steps will reproduce the problem?
1. Create a row vector, e.g. v = cvCreateMat(1,3,CV_32FC1)
2. Call as_numpy_array, v.as_numpy_array
3.

What is the expected output? What do you see instead?
ValueError: buffer is smaller than requested size

What version of the product are you using? On what operating system?
Ctypes-0.7.2 & OpenCV 1.1.0 on Mac OS X

Please provide any additional information below.

opencv/cv.py line 705
cv2DRotationMatrix should be _cv2DRotationMatrix

I need to use createsamples.exe and haartraining.exe to create and train a
sample. But I am getting side-by-side configuration error while running
createsamples.exe. Is any equivalent app or wrapper to this is availbale in
ctypes-openCV? Can we do haartraining in any manner using python wrapper?
Please suggest me.

Most of the data types defined using _Structure have nice repr
representations which reflects their field contents.  But CvScalar has a
single array field which doesn't show its values.  The attached patch to
trunk r102 adds a custom __repr__ to CVScalar to include the values in its
output.  It also contains a small adjustment to CVScalar construction to
permit anywhere from 1-4 parameters rather than just 1 or 4, and a tweak to
remove an extraneous c_double creation in the cvScalarAll constructor,
since the internal fields are floats to which input parameters are
converted anyway.

The attached patch (to trunk r102) adds a few missing default values for
some of the function prototypes (cvRemap, cvLogPolar, cvDrawContours and
cvSave).

I wanted to raise this because I don't have a quick solution, but would
like to see if there was some way to deal with it more gracefully.

The current ctypes helpers for wrapping (ByRefArg, ListByRef, ListPOINTER
and ListPOINTER2) work very well when the source of the data originates in
Python and is thus naturally in native Python data types.  They don't do so
well (and in fact some time preclude) using data as returned from OpenCV
itself.

For example, given a contour:

    polygon = cvApproxPoly(contour, sizeof(CvContour), storage,
                           CV_POLY_APPROX_DP, 100)
    points = (CvPoint * polygon.total)()
    cvCvtSeqToArray(polygon, points, cvSlice(0, polygon.total))

I've now got the points in a C-array, and would like to draw it, but I
can't just do:

    cvPolyLine(frame, [points], cvScalarAll(0))

even though that's most efficient, because the wrapper uses ListPOINTER2
which requires that the inner element be a tuple/list.  Instead I have to:

    cvPolyLine(frame, [tuple(points)], cvScalarAll(0))

but this requires walking the C array points to turn it into a Python level
tuple, but then ListPOINTER2 creates a brand new ctypes array data type,
re-walks my tuple and re-creates the C array.  That's great if all I had
was a Python tuple to start with, but for returned data (that may be
largish arrays), it's a bunch of unneeded time and space.

And unlike some other simplified wrappers, I can't bypass this without
defining my own wrapping function since the issue is with the core
definition of _cvPolyLine (and use of ListPOINTER2) and not the higher
level Python cvPolyLine wrapper.

ByRefArg isn't necessary as inefficient but it can still require
unnecessary temporary ctypes wrapper object creation.  If I receive a
pointer to the correct type of object from OpenCV, I can't pass it directly
back to another function but have to first create a ctypes object from
which byref() will just yield the same address.

An example of this is using cvLoad where I don't need access to the actual
data type (e.g., I don't need to access matrix data), but just want to pass
the returned object back to another function like Undistort2.  It also
covers my recent histogram patches, where dereferencing ".contents" of
hist.bins would be unnecessary if ByRefArg would pass hist.bins through
unchanged, since it's already the proper reference.

Originally I tried some changes for trying to identify if the parameter was
the proper data type, passing through unchanged in that case but it can be
tricky (e.g., the cvLoad case might not pass that test).  

So maybe the better approach is to be more limiting in what the wrappers
perform extra processing on, and in other cases just pass through the
parameter leaving it up to the caller to get it right or get ctypes level
errors.  Since their "assistance" is really designed for when you
specifically have one of the wrapper objects, it should be easy enough to
test against.  That would also avoid the need for special checking of None,
since it would pass through just like other unexpected types.  

Anyway, figured I'd throw it out - I don't want to interfere with the help
the wrappers do provide in the vast majority of cases but would like to be
able to preserve efficient round tripping of OpenCV created objects as well
if possible.

-- David

PS: Slightly related, but barring some changes such as above, should
ListByRef and ListPOINTER have errors if the parameter is something other
than expected, or perhaps better, return the parameter as supplied? 
Otherwise, a non-tuple/list parameter ends up being turned silently into
None/NULL when passed on to OpenCV, which bit me once or twice.

I found the support for the "cv" namespace within the package convenient
when using CVtypes - it prevents having to import 1000+ names into the
local namespace, while the combination of the namespace and shorter
function names is just as efficient (e.g., cv.CreateMat).  Attached is a
patch against trunk r102 that adds support for creating this namespace. 
It's an enhanced version I had from the CVtypes implementation that handled
a few other cases (such as turning CV_32F into just 32F being less than
helpful since cv.32F isn't a valid identifier in Python - so this version
leaves an underscore in such a case).

The attached patch corrects a few cvGetHistValue* function issues:
- Extra parameter on cvGetHistValue_1D
- They all passed a final 0 parameter to cvGetPtr* which, unlike C, won't
work as a pointer.  Removed to let cvGetPtr* defaults take over.
- They should return a float*, so added appropriate cast.

The highgui wrappers for window mouse callbacks and trackbar position
callbacks grows an internal list forever, although OpenCV just replaces
callbacks with newer versions.  My test environment was calling
cvSetMouseCallback for each image displayed, and between a lot of windows
and many iterations, the process grew to several hundred MB over a day of
testing.  More recent testing to track this down with 2 windows processing
~20fps for a few hours grew the process about 100k.

Anyway, I switched the callback function dictionary cache to use a
dictionary to hold the mouse/trackbar callbacks so they could be replaced.
 A patch is attached based on trunk r179.

Note that I have made minimal use of trackbars myself, but had to tweak
that code too since they share the cache with the mouse callbacks.  The
demos all seem to run fine though.

While seeing about packaging up a background image thread I've been using
on Windows (which OpenCV doesn't support natively) I realized I had
implemented some of the same support the highgui module already does for
trackbars, but for mouse callbacks.  So it seemed like the highgui module
should probably take care of similar stuff for mouse callbacks.

Namely, the parameter might not be a c_void_p but some other ctypes type,
and that a reference to the parameter should be kept for safety.  So the
attached patch adds that for mouse callbacks, as well as permits a None
callback (to remove it) similar to the recent patch for None trackbar
callbacks.

There's probably an enhancement that would permit passing in arbitrary
Python objects (e.g., an internal highgui ctypes type that also kept a
reference to the Python object), but I left that for later, as you can't do
that right now anyway.

What steps will reproduce the problem?

left=cvCreateMat(480, 640, CV_8U)
right=cvCreateMat(480, 640, CV_8U)
state=cvCreateStereoBMState()
cvFindStereoCorrespondenceBM(left, right, None, state)

What is the expected output? What do you see instead?

Should internally create and return disparity. Instead we get an error window:

Null pointer (Stereo BM state is NULL.)
in function cvFindStereoCorrespondenceBM, .\cvstereobm.cpp(574)

What version of the product are you using? On what operating system?

ctypes-opencv 0.7.3
OpenCV 1.1.0
Python 2.6

Windows XP Professional SP3


Please provide any additional information below.

From looking at the C source, this error triggers when the state parameter
passed in is NULL, which is strange because prior to the call, the state
parameter is non-null.

Same thing happens if I supply my own disparity parameter instead of having
it be internally created.

A strange thing I noticed in the debugger is that after setting a
parameter, the addresses of the fields inside it change. E.g:

# the object beforehand
CvStereoBMState(preFilterType=0,preFilterSize=41,preFilterCap=31,SADWindowSize=1
5,minDisparity=0,numberOfDisparities=64,textureThreshold=10,uniquenessRatio=15,s
peckleWindowSize=0,speckleRange=0,preFilteredImg0=<opencv.cxcore.LP_CvMat
object at 0x01A80A30>,preFilteredImg1=<opencv.cxcore.LP_CvMat object at
0x01A809E0>,slidingSumBuf=<opencv.cxcore.LP_CvMat object at 0x01A80A30>)

>>> state.SADWindowSize = 41

# the object after executing this line, note address changes.
CvStereoBMState(preFilterType=0,preFilterSize=41,preFilterCap=31,SADWindowSize=4
1,minDisparity=0,numberOfDisparities=64,textureThreshold=10,uniquenessRatio=15,s
peckleWindowSize=0,speckleRange=0,preFilteredImg0=<opencv.cxcore.LP_CvMat
object at 0x01A809E0>,preFilteredImg1=<opencv.cxcore.LP_CvMat object at
0x01A80A30>,slidingSumBuf=<opencv.cxcore.LP_CvMat object at 0x01A809E0>)

I am not sure if this has anything to do with it, but thought I would
mention just in case.

So I had a little time tonight to look into the crashes at the end of demos
that weren't closing all their own windows (such as edge.py).  I narrowed
it down to cases where a trackbar was created.  

My suspicion is that the interpreter cleanup is getting rid of the ctypes
objects cached in _windows_callbacks earlier than the highgui window
destruction and something in the OpenCV highgui module tries to reference
them.  I can't identify a precise case looking at the OpenCV code (and I
tried even without a value pointer or callback), but adding an atexit to
the highgui module that destroys all windows early in the interpreter
shutdown fixes the crash, so I'm thinking it's a reasonable thing to do.

Along the way I discovered that the current cvCreateTrackbar can't actually
create trackbars without a callback - None doesn't pass the ctypes
parameter check for a callback function.  So based on an old ctypes mailing
list thread, I defined a NULL pointer value cast to the callback type that
is permitted, and use that when no callback is specified.

-- David

I'm attempting to get the coordinates of matched circles, but I can't get
CvMat to iterate, and CvPoint returns huge x and y values:

from opencv import *

C = {} # dict of open camera captures

# returns an image from cam
def get_frame(cam):
    if not cam in C.keys():
        capture = cvCreateCameraCapture(cam)
        if capture:
            C.update({cam: capture})
        else:
            print "Capture failed on camera", cam
            return None
    return cvQueryFrame(C[cam])

def match_circles(img):
    grayscale = cvCreateImage(cvGetSize(img), 8, 1)
    storage = cvCreateMemStorage(0)

    cvConvertImage(img, grayscale)
    cvSmooth(grayscale, grayscale, CV_GAUSSIAN, 9, 9)
    circles = cvHoughCircles(grayscale, storage, CV_HOUGH_GRADIENT, 2,
grayscale.height, 200, 100)
    return circles

if __name__ == '__main__':
    c = 0
    cvNamedWindow("Raw Input", 1)
    while c != 27:
        image = get_frame(0)
        circles = match_circles(image)
        for l in circles.asarray(CvMat):
            for p in l:
                print p

        c = cvWaitKey(10)
        cvShowImage("Raw Input", image)
    cvDestroyAllWindows()

-----
Traceback (most recent call last):
  File "/home/liveuser/Desktop/roboticsai/vision/__init__.py", line 45, in
<module>
    for p in l:
  File "/usr/lib/python2.5/opencv/cxcore.py", line 827, in __iter__
    yield cvGetRows(self, i, i+1)
TypeError: cvGetRows() takes at least 4 arguments (3 given)
-----

cvHoughCircle is supposed to return either a CvSeq of circles, or a CvMat
of circle locations. Replacing circles.asarray(CvMat) with
circles.asarray(CvPoint) gives outputs like:

CvPoint(x=1135017984,y=1133838336)

Does anyone know how to get position data out of the returned value from
cvHoughCircle?

The attached patch changes the cx namespace slightly so that CvXxx
structure/data type names always get a leading underscore rather than only
upon collision.  The old way, data type names could change if a new
distinct function constructor gets added later (as was the case with the
introduction of cvMat in r172).  This will help ensure the data types stay
consistent.

-- David

I follow the step in 
http://www.site.uottawa.ca/~laganier/tutorial/opencv+directshow/cvision.htm
 site and after few step i'm getting 
"fatal error LNK1181: cannot open input file 'cxcore.lib'"
after linking the CV lib to the project and and typed the code which uses 
open cv lib

What is the expected output? What do you see instead?
there suspose not to have sny error just a program that can open image 

What version of the product are you using? On what operating system?
i'm using xp home , visual studio 2005 and downloaded opencv from sourge 
forge . direct x sdk (june 2008)


Please provide any additional information below.

hope some one can help as i need to learn fast to create my project ..

What steps will reproduce the problem?

Run the following code:

from opencv import cx as cv

im = cv.LoadImage("test.bmp") # simple test image, attached
bw = cv.CreateImage(cv.GetSize(im), cv.IPL_DEPTH_8U, 1)
cv.CvtColor(im, bw, cv.RGB2GRAY) # convert to 8-bit 1 channel for scanner
storage = cv.CreateMemStorage()
scanner = cv.StartFindContours(bw, storage)
cv.FindNextContour(scanner) # throws RuntimeError :(

What is the expected output? What do you see instead?

FindNextContour should return null or the next contour. Instead, the
following exception occurs:

Traceback (most recent call last):
  File "C:\Documents and Settings\ckmacleod\Desktop\test.py", line 8, in
<module
>
    cv.FindNextContour(scanner)
  File "C:\Python26\lib\site-packages\opencv\cv.py", line 1200, in
cvFindNextCon
tour
    return pointee(_cvFindNextContour(scanner))
RuntimeError: ffi_prep_cif failed

What version of the product are you using? On what operating system?

ctypes-opencv 0.7.3
OpenCV 1.1.0
Python 2.6

Windows XP Professional SP3

Please provide any additional information below.

What steps will reproduce the problem?
1. image = cvLoadImage('test.jpg',1)
2. patch = cvGetSubRect(image, None, cvRect(x,y,width,height))
3.

What is the expected output? What do you see instead?

An image patch defined by (x,y,width, height).
CvArr()

What version of the product are you using? On what operating system?
0.7.2 mac os x 

Please provide any additional information below.

What steps will reproduce the problem?

CvMoments().m01

What is the expected output? What do you see instead?

Should return 0.0. Instead:

AttributeError: 'CvMoments' object has no attribute 'm01'

What version of the product are you using? On what operating system?

ctypes-opencv 0.7.3
OpenCV 1.1.0
Python 2.6

Windows XP Professional SP3

Please provide any additional information below.

Seems like this field was simply forgotten in the wrapper, and all we need
to do is add it in line 45 of cv.py. I would submit a patch but I'm new to
this and don't know how.

It's sort of a borderline case, but if a mouse callback is set or a
trackbar created for a non-existent window, it currently generates a
KeyError trying to update the _windows_callbacks cache.

The underlying highgui functions do not fail in such a case, silently
ignoring the request, so this patch mirrors that behavior.  I suppose
there's also a small realm of possibility of having Python code in the same
process as C code where the Python code wants to reference a window created
in the C code (and thus not known to highgui.py).

The other possibility would be to raise a Python-specific exception if it
got a window name it knew it didn't create.  But I think either this patch
or a specific exception would be better than a KeyError on an internal
object to the module, which isn't going to make sense to a user.

-- David

The function wrapper for cvHoughCircles was missing the final two
parameters.  (They weren't in CVtypes either, but are in OpenCV 1.0, so
perhaps they got added before it made 1.0)

Attached is a patch to add them based on the current trunk (r179).

What steps will reproduce the problem?
1. find chessboardcorners with cvFindChessboardCorners()
2. try to calibrate camera with cvCalibrateCamera2()
3.

What is the expected output? What do you see instead?
I expected camera intrinsics and distortion coeffs returned. Instead, I 
got:
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: Don't 
know how to convert parameter 1

What version of the product are you using? On what operating system?
OpenCV 1.0 with ctypes-opencv 0.7.2 on Windows XP

Please provide any additional information below.
Actually this is rather weird because I could calibrate camera without a 
problem last time. I was calling calibrate camera in a window method, and 
then decided to make my own camera class which has calibration-related 
methods in it. However, the error message implies that I passed a 
parameter of wrong type. Argument 1, object_points, should be cvMat, which 
it exactly is. This is full traceback message:

Traceback (most recent call last):
  File "D:\workspace\Doonoon\gui\Doonoon_frame.py", line 383, in Calibrate
    cam.calibrate()
  File "D:\workspace\Doonoon\gui\Doonoon_frame.py", line 161, in calibrate
    ( intrinsic, distortion ) = cvCalibrateCamera2( byref
(self.object_points), self.image_points, self.point_counts, cvGetSize( 
img ), self.intrinsic_matrix, self.distortion_coeffs, None, None, 0 )
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: Don't 
know how to convert parameter 1

This is what I got when I print argument 1 (objects_points)

CvMat
(type=1111638021,step=12,refcount=66116416,hdr_refcount=1,data=<opencv.cxco
re.CvMatData object at 0x0236FD50>,r=<opencv.cxcore.CvMatRows object at 
0x0236FB70>,c=<opencv.cxcore.CvMatCols object at 0x0236FE40>)

This is the code in which the matrices are generated and used:

    self.intrinsic_matrix  = cvCreateMat( 3, 3, CV_32FC1 )
    self.distortion_coeffs = cvCreateMat( 4, 1, CV_32FC1 )
    self.point_counts      = cvCreateMat( self.n_boards, 1, CV_32SC1 )
    self.image_points      = cvCreateMat( self.n_boards * self.board_n, 2, 
CV_32FC1 )
    self.object_points     = cvCreateMat( self.n_boards * self.board_n, 3, 
CV_32FC1 )
    ...
    ...
      for j in range( self.board_n ):
        #print i, j
        self.image_points[i,0] = corners[j].x
        self.image_points[i,1] = corners[j].y
        self.object_points[i,0] = j / self.board_w
        self.object_points[i,1] = j % self.board_w
        self.object_points[i,2] = 0.0
        i+= 1
        j+= 1
      self.point_counts[self.success_count,0] = self.board_n
    ...
    ...
    self.intrinsic_matrix[0,0] = 1.0
    self.intrinsic_matrix[1,1] = 1.0
    ( intrinsic, distortion ) = cvCalibrateCamera2( self.object_points, 
self.image_points, self.point_counts, cvGetSize( img ), 
self.intrinsic_matrix, self.distortion_coeffs, None, None, 0 )

Sound like a troubleshooting than an issue. Sorry for that. Thanks.

I ran into a pair of other functions (AdaptiveThreshold and CopyMakeBorder)
with some missing prototype parameter defaults, so rather than keep hitting
these one off, I walked through the modules and tried to check all the
functions.  Most of the missing stuff were those that weren't constant
values.  I also corrected one or two documentation string discrepancies -
generally minor.  Imports correctly (and demos run) with OpenCV 1.0 and 1.1.

The attached patch is against trunk @183

Code to reproduce:

--------------------------------------------------------------------

from opencv.cv import *
from opencv.highgui import *

if __name__ == "__main__":
    object = cvLoadImage( "test.jpg", CV_LOAD_IMAGE_GRAYSCALE )

    objectKeypoints = CvSeq()
    objectDescriptors = CvSeq()
    storage = cvCreateMemStorage( 0 )

    cvExtractSURF( object, 0, objectKeypoints, objectDescriptors, storage,
cvSURFParams( 500, 1 ) )
    print "Object Descriptors: %d" % objectDescriptors.total

--------------------------------------------------------------------

System:
Linux bolt 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009
i686 GNU/Linux
Ubuntu 9.04

Expected:
Object Descriptors: 300 (ish)

Outcome:
OpenCV ERROR: Internal error (Assertion: img != 0 && CV_MAT_TYPE(img->type)
== CV_8UC1 && (mask == 0 || (CV_ARE_SIZES_EQ(img,mask) &&
CV_MAT_TYPE(mask->type) == CV_8UC1)) && storage != 0 &&
params.hessianThreshold >= 0 && params.nOctaves > 0 && params.nOctaveLayers
> 0 failed)
    in function cvExtractSURF, cvsurf.cpp(291)
Terminating the application...

Using latest release version 0.7.3

While 2to3 can be run to convert the package to a Python 3.0 compatible
source, there are actually minimal changes needed to avoid the need for
such a conversion.  It's mostly adjusting relative imports to absolute,
replacing xrange with range, and fixing some errors in exception generation.

So this patch (to trunk r102) supplies changes that produce a 3.0
compatible package.  To minimize performance/memory, it continues to use
xrange if available.

Simple script similar to example in documentation:
  from ctypes_opencv import *
  mat = cvCreateMat( 3, 3, CV_32F )
  fs = cvOpenFileStorage("example.yml", None, CV_STORAGE_WRITE)
  cvSetIdentity(mat)
  cvWrite( fs, "A", mat, cvAttrList())

generates following error:
  Traceback (most recent call last):
    File "cvtest2.py", line 7, in <module>
      cvWrite( fs, "A", mat, cvAttrList() );
  ctypes.ArgumentError: argument 3: <type 'exceptions.TypeError'>: wrong type

I'm using opencv-1.1.0-pre build with gentoo ebuild and ctypes-opencv from svn.

Running this code with img = cvQueryFrame(capture):

def find_circles(img):
    gray = cvCreateImage(cvGetSize(img), 8, 1)
    storage = cvCreateMemStorage(0)
    cvCvtColor(img, gray, CV_BGR2GRAY)
    cvSmooth(gray, gray, CV_GAUSSIAN, 9, 9)
    print cvHoughCircles(gray, storage, CV_HOUGH_GRADIENT, 2,
int(gray['height'])/4, 200, 100)

Throws this error:

Traceback (most recent call last):
  File "/home/liveuser/Desktop/bot/CVtypes/vision.py", line 70, in <module>
    find_circles(src)
  File "/home/liveuser/Desktop/bot/CVtypes/vision.py", line 45, in find_circles
    print cvHoughCircles(gray, storage, CV_HOUGH_GRADIENT, 2,
int(gray['height'])/4, 200, 100)
  File "/usr/lib/python2.5/opencv/cxcore.py", line 493, in __getitem__
    pixel = self.get_pixel(key)
  File "/usr/lib/python2.5/opencv/cxcore.py", line 474, in get_pixel
    raise KeyError("Key (%s) is not a tuple of 2 integers." % str(key))
KeyError: 'Key (height) is not a tuple of 2 integers.'



Running Fedora 10 off a USB drive, Logitech webcam, Python 2.5 installation

From the interfaces numpy to ipl conversors I was getting an error after
creating an exe with py2exe:

C:\Python25\Lib\site-packages\biokit\demo\dist>verifier_gui_demo.exe
importing modules
imported lse
importing crossmatchmanager
importing biokit.commun.quality_control
importing Image
importing struct
importing math
importing ctypes
importing opencv
Traceback (most recent call last):
  File "verifier_gui_demo.py", line 6, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "biokit\sbin\CrossmatchManager.pyo", line 33, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "biokit\commun\quality_control.pyo", line 11, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "opencv\__init__.pyo", line 21, in <module>
  File "zipextimporter.pyo", line 82, in load_module
  File "opencv\interfaces.pyo", line 93, in <module>
  File "ctypes\__init__.pyo", line 353, in __getattr__
  File "ctypes\__init__.pyo", line 358, in __getitem__
AttributeError: function 'PyBuffer_FromReadWriteMemory' not found

From this part of the interfaces:

#-----------------------------------------------------------------------------
# numpy's ndarray -- by Minh-Tri Pham
#-----------------------------------------------------------------------------

It only catches an ImportError:

except ImportError:
    pass

I added a general except and it works now. I didn't look in detail if it
was a py2exe or interfaces error.

The strange part is below:

C:\Python25\Lib\site-packages\biokit\demo\dist>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> from_memory = pythonapi.PyBuffer_FromReadWriteMemory
>>>

So it is some kind of bug somewhere, as you may see that this didn't make
any error !

Thanks,

Running this code with img = cvQueryFrame(capture):

def find_circles(img):
    gray = cvCreateImage(cvGetSize(img), 8, 1)
    storage = cvCreateMemStorage(0)
    cvCvtColor(img, gray, CV_BGR2GRAY)
    cvSmooth(gray, gray, CV_GAUSSIAN, 9, 9)
    print cvHoughCircles(gray, storage, CV_HOUGH_GRADIENT, 2,
int(gray['height'])/4, 200, 100)

Throws this error:

Traceback (most recent call last):
  File "/home/liveuser/Desktop/bot/CVtypes/vision.py", line 70, in <module>
    find_circles(src)
  File "/home/liveuser/Desktop/bot/CVtypes/vision.py", line 45, in find_circles
    print cvHoughCircles(gray, storage, CV_HOUGH_GRADIENT, 2,
int(gray['height'])/4, 200, 100)
  File "/usr/lib/python2.5/opencv/cxcore.py", line 493, in __getitem__
    pixel = self.get_pixel(key)
  File "/usr/lib/python2.5/opencv/cxcore.py", line 474, in get_pixel
    raise KeyError("Key (%s) is not a tuple of 2 integers." % str(key))
KeyError: 'Key (height) is not a tuple of 2 integers.'



Running Fedora 10 off a USB drive, Logitech webcam, Python 2.5 installation

What steps will reproduce the problem?
1. create ipl image of type IPL_DEPTH_32S
2. check that its depth field is equal to -2147483616 insted of IPL_DEPTH_32S
3. call image.as_numpy_array()

What is the expected output? What do you see instead?
the expected output is a numpy array containing the same data as the ipl
image object. Instead, interpreter failed to execute as_numpy_array() due
to unrecognized value -2147483616

What version of the product are you using? On what operating system?
ctypes-opencv 0.8
python 2.5
windows xp

Please provide any additional information below.
calling image.as_numpy_array() fails because this value is the int32
"complement" of IPL_DEPTH_SIGN + 32 and thus is not found inside
ipldepth2dtype (which expects IPL_DEPTH_SIGN + 32)

This problem seems to belinked with a constant coded as usigned int and a
field coded as int.

What steps will reproduce the problem?
1. Create a float matrix (M) using cvCreateMat
2. Access the matrix by column using M[:,col_idx]
3.

What is the expected output? What do you see instead?
For eg,
M = [0,1,2,3;
         4,5,6,7] with type CV_32FC1
M[:,0] gives [0;4] as expected, whereas M[:,i] i=1,2,3 gives wrong result.

What version of the product are you using? On what operating system?
Ctypes-0.7.2 & OpenCV 1.1.0 on Mac OS X

Please provide any additional information below.

While working on some other stuff, I stumbled across a tiny item -
cvSetIdentity is missing a default value for the scalar.  Diff attached.

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.

I am showing camera input in a window, and from time to time recording and 
saving it to a file. 

To trigger the saving I use cvWaitKey(). 
OpenCV highgui reference says "This function is the only method in HighGUI that 
can fetch and handle 
events" http://opencv.willowgarage.com/documentation/python/user_interface.html

How is it possible to have a script internal logic to initiate e.g. a recoding 
of 10''? 
When I have cvWriteFrame() in a while loop, no frame will be updated in the 
window for the time of 
recording. 

I've tried to put the recording code into a python thread, no luck. 
Executing the recording code as a subprocess and piping key commands via stdin 
to it is very clumsy and 
doesn't work because the main script waits until the subprocess has terminated. 
Meaning i cannot execute  
any timing logic in the parent script. 

What am I missing?
Best
Raphael



#############################################################
#!/usr/bin/env python

from ctypes_opencv import *

window = cvNamedWindow('Camera', CV_WINDOW_AUTOSIZE)
cvMoveWindow('Camera', 10, 10)
capture = cvCreateCameraCapture(0) 
writer = cvCreateVideoWriter ("captured.mpg", CV_FOURCC('P','I','M','1'), 30, 
(640,480), True)

if __name__ == '__main__':

    while 1:
        frame = cvQueryFrame(capture)
        cvShowImage('Camera', frame)    

        # record
        if cvWaitKey (5) & 255 == 114:  # wait for 'r'
            cvWriteFrame(writer, frame) 

        # stop recording when 's' is received
        if cvWaitKey (5) & 255 == 115:   # s
            break

#############################################################

What steps will reproduce the problem?

Attempt to iterate over a CvMat, e.g.:

list(cvCreateMat(3, 3, CV_32FC3))

What is the expected output? What do you see instead?

I expect a list of the rows in the structure. Instead, TypeError is raised:

Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26\lib\site-packages\opencv\cxcore.py", line 827, in __iter__
    yield cvGetRows(self, i, i+1)
TypeError: cvGetRows() takes at least 4 arguments (3 given)

What version of the product are you using? On what operating system?

ctypes-opencv 0.7.3
OpenCV 1.1.0
Python 2.6

Windows XP Professional SP3

Please provide any additional information below.

It seems to work as I expect if in cxcore.py line 827, I add "None" as the
second argument. This causes the second argument submat to be internally
created by cvGetRows. 

The same thing affects CvMat.colrange and possibly other places as well?

On posix systems, the current detect_opencv() is using load_library while
incorrectly supplying the "lib" prefix as part of the library name.  It
happens to work on OSX since find_library() there tries both with and
without lib, but fails under Linux.  Attached is a proposed patch (against
trunk rev 102) to simply load the most recent .so/.dylib, rather than
trying to hardcode .2 or .1.

What steps will reproduce the problem?
1. use cvSmooth(src, dst, CV_Bilateral, param1, param2, param3, param4)
2. set param2 = 0
3. watch it fail

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.
the cvSmooth function needs to accept 7 arguments. The ctype wrapper only
accepts 6. 

change the wrapper in cv.py for cvSmooth to read:

cvSmooth = cfunc('cvSmooth', _cvDLL, None,
    ('src', CvArr_r, 1), # const CvArr* src
    ('dst', CvArr_r, 1), # CvArr* dst
    ('smoothtype', c_int, 1, CV_GAUSSIAN), # int smoothtype
    ('param1', c_int, 1, 3), # int param1
    ('param2', c_int, 1, 0), # int param2
    ('param3', c_double, 1, 0), # double param3
    ('param4', c_double, 1, 0), # double param4
)

The current cvLoadCast implementation just casts the memory pointer to a
pointer to the correct object type.  However, unlike with CVtypes, such a
pointer is no longer valid for use in many functions since parameters are
wrapped as ByRefArg, which requires a full Python-side ctypes object.

This patch (against trunk r102) changes cvLoadCast to use the from_address
method of the ctype-type, which results in a full object that is then
usable against functions defined with ByRefArg.