Hi, currently the following test fails on my system: test_opencv_cv.TestCalibrateCamera2.test_cvCalibrateCamera2_Identity ... OpenCV ERROR: Bad argument (Distortion coefficients must be 4x1 or 1x4 floating-point matrix) in function cvCalibrateCamera2, cvcalibration.cpp(1350) This is a bit ironic, since it is a test that I initially wrote. The Problem is that the function cvCalibrateCamera2 now allocates an distortion array of size 1x5 while before it allocated a distortion array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i currently use) uses 1x4. The Problem (once again!) rises that we do not link against a particular version of the opencv but instead to our very own hotlinking when the lib is loaded. This leads to this obscure crash without any feedback to the user. Thus, I vote again for autodetection and proper linking against headers. OR, if this is too much trouble at least deny loading OpenCV 1 at run time, because we just can not be too sure what the problems are. Another point: generated c files in the repository are constantly comming up as changed or merge conflicts for me. What is the reason to keep .c files in the repository; i think it is fair to assume that python developers who have a c compiler installed will also have cython installed to generate the .c files. Holger
Hi Holger 2009/11/4 SirVer <sirver@gmx.de>:
The Problem is that the function cvCalibrateCamera2 now allocates an distortion array of size 1x5 while before it allocated a distortion array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i currently use) uses 1x4.
Should should make it a priority to figure out which version of OpenCV is available before releasing 0.3. Do you have any ideas? I was hoping they'd have a function such as version(), but I think I'm out of luck.
Another point: generated c files in the repository are constantly comming up as changed or merge conflicts for me. What is the reason to keep .c files in the repository; i think it is fair to assume that python developers who have a c compiler installed will also have cython installed to generate the .c files.
This has been a constant source of annoyance, so I wonder whether we shouldn't just stop tracking the C files. We could always still include C files in the source distribution. Regards Stéfan
2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>
Another point: generated c files in the repository are constantly comming up as changed or merge conflicts for me. What is the reason to keep .c files in the repository; i think it is fair to assume that python developers who have a c compiler installed will also have cython installed to generate the .c files.
This has been a constant source of annoyance, so I wonder whether we shouldn't just stop tracking the C files. We could always still include C files in the source distribution.
Diffs are also hard to read with C file changes, so +1 for this. I just discovered that Cython is one of the few non-pure-python packages that actually easy-installs on my machine, so it looks like a very light-weight dependency. Cheers, Ralf
And the problem with linking header files is that it makes OpenCV a dependency. This brings a couple problems: 1) The user has to install OpenCV. Until 2.0 is in the repos, this is much to ask of a new user, who could use everything else meantime. 2) We have to find the header files on the users machine, or provide a way for them to provide it. For no REAL benefit. If the opencv API changes, you claim that linking the headers will allow us to fix these crashing problems. I disagree. In Cython when you do a: cdef extern from "whatever.h": void cvFunc(IplImage*, IplImage*, CvPoint2D32F*) That is only for Cythons benefit. It just puts an #include directive in the foo.c file. So in the case of this most recent test failing, the error would NEVER be caught, neither by the C compiler or Cython. Because neither have a way of knowing how big CvPoint2D32F* array should be. Now lets say that OpenCV 2.1 comes out, and they change the api for cvFunc, and we dont realize it. Let's say the new signature becomes: void cvFunc(IplImage*, IplImage*, IplImage*). Because of how cython works, the cython module will still compile (it doesnt ever look in the .c headers). However, the error will likely be caught by GCC. So now what you have, (if we make the headers a dependency), is someone who cant install the scikit AT ALL, rather than just a part of a scikit with some tests that will fail... This is the entire reason to have a testing framework. I though about this one for a while. and I vehemently oppose linking to the cv headers. Cheers, Chris On Wed, Nov 4, 2009 at 10:11 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>
Another point: generated c files in the repository are constantly comming up as changed or merge conflicts for me. What is the reason to keep .c files in the repository; i think it is fair to assume that python developers who have a c compiler installed will also have cython installed to generate the .c files.
This has been a constant source of annoyance, so I wonder whether we shouldn't just stop tracking the C files. We could always still include C files in the source distribution.
Diffs are also hard to read with C file changes, so +1 for this.
I just discovered that Cython is one of the few non-pure-python packages that actually easy-installs on my machine, so it looks like a very light-weight dependency.
Cheers, Ralf
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
I just discovered that Cython is one of the few non-pure-python packages that actually easy-installs on my machine, so it looks like a very light-weight dependency.
Could we petition for OpenCV to have a __version__() function? Stéfan
OpenCV has a ___version___ header file. Catch 22 2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
I just discovered that Cython is one of the few non-pure-python packages that actually easy-installs on my machine, so it looks like a very light-weight dependency.
Could we petition for OpenCV to have a __version__() function?
Stéfan
its not exposed as a function, just a #DEF Goodluck with getting that done though. I doubt we will see a new OpenCV release for awhile... and people will be using 2.0 for a long time to come... 2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
OpenCV has a ___version___ header file.
We can only access that if it exposed as a function, though, so maybe they can help us out.
Cheers Stéfan
A __version__ function in the future is little help to distinguish between OCV 1 and OCV 2. BUT the current case is not bearable; for example the test suite can not be run when you have OpenCV 1 installed, because OpenCV errors always result in a coredump because of their braindumped I-do-my-own-Exceptions-In-C-Which-Are-Uncatchable Stuff. That is, as soon as the opencv tests run, the whole python process is KILLED by opencv throwing an exception because I expects an array of 1x5 instead of 1x4. (Note that the same is true if we do stuff vice-versa: making version 1 a dependency and the user has 2 installed). The only REAL solutions I see for this mess is to either a) decide which version to build against at build time using IFDEFs. Which is ugly and not easy to pull off and makes OpenCV a hard build time dependency. On plus we would have to ship binary versions linked against OCV1 and OCV2. Ugly code, Ugly distribution, hard to implement. b) Determine at run time if the user has OpenCV 1 installed and ABORT then in a pythonic fashion. I know of no portable way to pull this off; one could only check for relative positions of functions in the binaries or so. Nice code, nice distribution, very hard to implement. c) Rip the parts that we need from the OpenCV source code (if licensing allows that) and build our own subset of the functionality into scikit.image. No dependency on the OpenCV anymore, no cranky void* pointer passing around, no strange exceptions that are uncatchable. Heaven on earth. Downside: a lot of work. Upside: We really would provide the image processing capabilities. What do others think? Personally, I always wanted to have a better designed Image Library with a smaller, but well tested subset of ImageProcessing Algos that are really useful.
Goodluck with getting that done though. I doubt we will see a new OpenCV release for awhile... and people will be using 2.0 for a long time to come... No wonder; hacking OpenCV code is as ugly as coding can get.
Cheers, Holger
2009/11/4 Stéfan van der Walt <ste...@sun.ac.za>:
2009/11/4 Chris Colbert <sccolb...@gmail.com>:
OpenCV has a ___version___ header file.
We can only access that if it exposed as a function, though, so maybe they can help us out.
Cheers Stéfan
2009/11/4 Ralf Gommers <ralf.gommers@googlemail.com>:
Diffs are also hard to read with C file changes, so +1 for this.
I just discovered that Cython is one of the few non-pure-python packages that actually easy-installs on my machine, so it looks like a very light-weight dependency.
This is now done. The .c files are still generated for inclusion with the sdist. Cheers Stéfan
There are many minor annoyances that we ran into in some functions that make it near impossible to support both opencv versions regardless of whether or not we link header files. For example, cvIntegral in 2.0 calculates the titlted_sum for any dtype, while 1.x does not. Stefan and I realized during the sprint that this would cause us to be IF_THEn_ELSE'ing all over the place, making the code ugly, just to support a 5 year old version of the library. (there are more examples than just this one) We thought it would be better to make OpenCV 2.0 a dependency, and lobby ubuntu to update the OpenCV packages. Cheers, Chris 2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>:
Hi Holger
2009/11/4 SirVer <sirver@gmx.de>:
The Problem is that the function cvCalibrateCamera2 now allocates an distortion array of size 1x5 while before it allocated a distortion array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i currently use) uses 1x4.
Should should make it a priority to figure out which version of OpenCV is available before releasing 0.3. Do you have any ideas? I was hoping they'd have a function such as version(), but I think I'm out of luck.
Another point: generated c files in the repository are constantly comming up as changed or merge conflicts for me. What is the reason to keep .c files in the repository; i think it is fair to assume that python developers who have a c compiler installed will also have cython installed to generate the .c files.
This has been a constant source of annoyance, so I wonder whether we shouldn't just stop tracking the C files. We could always still include C files in the source distribution.
Regards Stéfan
participants (4)
-
Chris Colbert -
Ralf Gommers -
SirVer -
Stéfan van der Walt