Closed GoogleCodeExporter closed 9 years ago
Thanks for the info you have provided. It's very helpful. First of all, did you
download a Boost source archive or did you use one of the libboost- packages
already
packaged on Ubuntu?
Original comment by pmtri80@gmail.com
on 5 Feb 2010 at 6:07
This error only occurs if I'm using the boost install that comes with Ubuntu.
Now I've tried to build it on my own
and pyopencv compiles just prefect. So the trick is to build boost from source.
Thanks for your quick help!
Original comment by rea...@imojo.de
on 6 Feb 2010 at 4:28
Great! Thanks for letting me know. Actually, right now I haven't got time to
tweak
the setup.py file to work with boost distributions other than the source
distribution. But I will work towards achieving that convenience.
Original comment by pmtri80@gmail.com
on 6 Feb 2010 at 8:13
Is this issue resolved?
I'm getting the same error while trying to package pyopencv. I can't continue
packaging if I can't use the boost packages supplied by ubuntu.
Original comment by gijsmole...@gmail.com
on 20 Apr 2010 at 1:44
Unfortunately, it is not resolved. See my comments on issue 7.
To be honest, if you were wondering why I have chosen bjam, I would say because
that
is the only build tool that appears to build a Python extension using
Boost.Python
correctly. I do not want to use bjam myself because it is rather difficult to
use.
However, I have not been able to build PyOpenCV successfully using other tools
like
distutils or scons. Using those tools, I obtained Python modules which crashed
on my
platforms. I would, however, be grateful if someone could tell me a successful
case
of building a Python extension using Boost.Python with tools other than bjam.
Cheers,
Minh-Tri
Original comment by pmtri80@gmail.com
on 20 Apr 2010 at 2:51
If the issue isn't fixed, it shouldn't be marked as Fixed. I'm getting the
same
error as well.
Either way, I don't think gijsmolenaar is complaining about bjam. The only
point is
that while pyopencv can't be compiled with the toolkit packaged within
distributions,
it won't reach a wider audience.
To be sincere, it looks like pyopencv would be a good replacement for the
extensions
which come by default with opencv, but it really has to get to the point where
it can
be built with packaged tools.
Original comment by n13m3y3r
on 4 May 2010 at 8:11
Thanks, n13m3y3r, for your comment. I've changed the status back to Accepted.
It's
not that I don't want pyopencv to reach a wider audience. However, right now
it's not
easy to fix this issue at all. If someone can help me out at fixing it, or at
least
point me to relevant sources, I will appreciate it. Otherwise, I'll try to look
at
the matter more deeply when I manage to get some spare time.
Cheers,
Minh-Tri
Original comment by pmtri80@gmail.com
on 4 May 2010 at 8:59
Thanks for your kind answer Minh-Tri. I will try to see if I can find someone
else
with experience with bjam to tell us if the problem is in the packaged version
of
Ubuntu, or if there's an alternative way for pyopencv to be doing whatever it
has to
do.
I'm finding another compilation issue now. I'll post it in another issue.
Original comment by n13m3y3r
on 5 May 2010 at 6:24
I just wrote a message to the boost maintainers in Debian. Let's see if they
can help
us.
Original comment by n13m3y3r
on 5 May 2010 at 6:46
Thank you very much for your help, n13m3y3r. On my end, I will try again to see
if
PyOpenCV can be built with scons. I have seen a successful use case of building
Boost.Python extensions using scons. If we can replace bjam with scons, all our
current issues with bjam will be resolved.
Cheers,
Minh-Tri
PS: Sorry for my late response, I had a very busy day yesterday.
Original comment by pmtri80@gmail.com
on 6 May 2010 at 8:56
I want to vote for using CMake as the build system for PyOpenCV. OpenCV is
built with
CMake. If PyOpenCV is also built with CMake, there is less new things to learn +
there is a higher chance that PyOpenCV will eventually take over the ctypes
OpenCV
python wrapper.
Original comment by dattan...@gmail.com
on 17 May 2010 at 3:50
Attached is part of the fix.
* Check out the source code into a src_folder
* Put this file into src_folder/pyopencv
* Use CMake (preferably GUI version) to configure your variables
* Compile
I haven't run the test suite of pyopencv on it.
Remaining things
* Run test suite on the generated .so file
* Add a post-build step to rename the .so file
* Add a pre-build step to run codegen.py so these generated pypp files are
actually
generated.
* Test on other platforms
Original comment by dattan...@gmail.com
on 18 May 2010 at 1:18
Attachments:
That's very cool, Dat. Thank you so much. I wonder why haven't I thought about
CMake
before. I am rather busy from now until Sep 2010 but I will patch as soon as I
can.
Cheers,
Minh-Tri
Original comment by pmtri80@gmail.com
on 18 May 2010 at 6:47
I have updated the CMakeLists.txt file so that it GLOB_RECURSE the C++ files
under
pyopencvext. This will creates a pyopencvext.so. If I put this pyopencvext.so
file in
the pyopencv folder. Running
import pyopencv
Doesn't give an error. However, when I try some simple code, I will get
"dimensions
too large error"
from pyopencv import *
a = Mat(3,5,CV_32FC3)
a.setTo(10)
Perhaps Tri will have an idea why this error might happen. I can then fix the
CMakeLists.txt file further so we all could have a CMake version of PyOpenCV
soon.
Original comment by dattan...@gmail.com
on 19 May 2010 at 3:40
Attachments:
"ValueError: dimensions too large" is an exception raised by numpy when an
ndarray
with a very large size is created. In your example, the only part that involves
a
creation of an ndarray is when Python invokes repr() to obtain a representation
string for the returning Mat object of the 'a.setTo(10)' function call. I
suspect
something is wrong at the part to create an ndarray view of a Mat object.
To confirm this, you could try 'a.setTo(10);' instead of 'a.setTo(10)' and see
if no
error is raised.
Original comment by pmtri80@gmail.com
on 19 May 2010 at 6:50
Ok, No error is raised. -_- I am confused. I thought that ; is optional in
Python.
Original comment by dattan...@gmail.com
on 19 May 2010 at 1:10
It is definitely optional at the end of a line in terms of parsing.
What difference is it making exactly, and in which context? Who's executing
these
lines, and what's the output in both cases?
Original comment by n13m3y3r
on 19 May 2010 at 1:35
The ';' character is optional in Python. But I thought you were using IPython.
In
IPython, ';' means don't print out the result of the current expression.
Original comment by pmtri80@gmail.com
on 19 May 2010 at 2:25
I believe that the problem lies with the (auto) conversion into Numpy. It seems
that
in order to display the matrix via print command (__repr__), the matrix is
converted
to Numpy.
When I run a.ndarray I will also get the same (i.e. ValueError: dimensions too
large).
Tri, can you explain briefly what is suppose to be built into the
pyopencvext.so?
Original comment by dattan...@gmail.com
on 19 May 2010 at 3:48
I have made my CMakeLists.txt a direct translation from the Jamroot file. The
problem
still remains. I have a hunch that this might have something to do with my
system
being 64-bit.
For this CMakeLists.txt file to work, put it in the pyopencv-2.1.0.wr1.0.2
folder.
Original comment by dattan...@gmail.com
on 20 May 2010 at 1:46
Attachments:
There's nothing special about building pyopencvext.so. All I did was telling
bjam to
compile every source file in the pyopencvext folder (recursively) and to link
them
altogether. What I am afraid is that bjam may include some platform-specific
compilation flags and linking flags, which are hidden from us, in order to
build C++
code properly.
To get to know which flags have been provided to gcc, try adding the '-v' flags
to
the compiler. To do this with PyOpenCV, all you have to do is to insert
"<compileflags>-v" to line 53 (i.e. the line containing "using gcc : : g++ :
<compileflags>-O3 ...") in the 'bjamcompiler.py' file, and run 'setup.py' again.
Original comment by pmtri80@gmail.com
on 20 May 2010 at 1:59
Oh, just saw your last post. Thanks.
Original comment by pmtri80@gmail.com
on 20 May 2010 at 2:00
Starting from r1025, PyOpenCV can be build via CMake (thanks Dat) as well as
via setuptools. bjam is no longer required. If you have time, please feel free
to try it out on your platform and let me know if there is any problem.
To install PyOpenCV via CMake:
mkdir build
cd build
cmake ..
make
make install
To install PyOpenCV via setuptools (PyOpenCV will automatically invoke CMake to
self-configure if the file 'config.py' is not found):
python setup.py install
For now, I'd like to close this issue. Thank you all very much for your
feedbacks.
Best regards,
Minh-Tri
Original comment by pmtri80@gmail.com
on 27 Aug 2010 at 7:53
Original issue reported on code.google.com by
rea...@imojo.de
on 5 Feb 2010 at 5:38