i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
+ a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
2012/12/12 Miller Puckette msp@ucsd.edu:
I tried and was able to make Gem externals that worked on linux and Mac OS, but on Windows I wasn't able to link eternals that needed Gem symbols. This was years ago though, and anyway I might have been missing something :)
m
On Wed, Dec 12, 2012 at 01:19:04PM -0500, Hans-Christoph Steiner wrote:
I think the best way to make it easy to find, download and install is to make binaries structured as libdirs and post them on puredata.info/downloads.
I think with a little work that we can make a Gem external template based on the Library Template. I've done it before quick and dirty, that's not hard.
.hc
On Dec 12, 2012, at 11:46 AM, Antoine Villeret wrote:
hello,
i realize that pix_opencv is not include anywhere and people have to search it in the SVN and to built it themselves
i'm wondering how we can help them to use this library i think it's a bit difficult to rewrite it's build system to fit the template because of the dependencies on Gem and OpenCV
but could it possible to include this library in Gem ? in the extras ? like pix_fiducial and others ?
what do you think about that ?
a
do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote:
i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
caveat: both Gem and pix-opencv are complex projects. Gem has slow release cycles, those of pix-opencv seems to be even more so. synchronizing both projects so that we can create a "stable" Gem-package including a "stable" pix-opencv could be impossible.
so in a way it would be better if pix-opencv was distributed separately, but actively.
fgmasdr Ihannes
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote:
i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
caveat: both Gem and pix-opencv are complex projects. Gem has slow release cycles, those of pix-opencv seems to be even more so. synchronizing both projects so that we can create a "stable" Gem-package including a "stable" pix-opencv could be impossible.
so in a way it would be better if pix-opencv was distributed separately, but actively.
I agree, lumping everything into one giant package makes it into a maintenance headache and centralizes that headache on IOhannes, since he's the lead maintainer of Gem. Its good to avoid it.
.hc
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote:
i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
caveat: both Gem and pix-opencv are complex projects. Gem has slow release cycles, those of pix-opencv seems to be even more so. synchronizing both projects so that we can create a "stable" Gem-package including a "stable" pix-opencv could be impossible.
so in a way it would be better if pix-opencv was distributed separately, but actively.
I agree, lumping everything into one giant package makes it into a maintenance headache and centralizes that headache on IOhannes, since he's the lead maintainer of Gem. Its good to avoid it.
i do agree too, but I think it could be good to distribute pix_opencv with Gem whenever it's possible and not too hurting for your head :-)
a.
.hc _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote:
i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a -- do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote:
i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
* is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
* pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resources
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a
do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote:
i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
- is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
- pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a
do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-12 19:42, Antoine Villeret wrote: > i've already tried to make a C++ external from the template but i > never reach something which works so if you have a working template > please let me know
pix-opencv depends on external libraries, and afaik often needs specific versions thereof. i think it is a perfect candidate to *not* use a template Makefile but instead use something more intelligent like autotools, scons, cmake,...which reminds me that it already does use autoconf
> and what about including it in Gem ? as it depends on it (and it > may depends on very new feature such as ROI soon) i think it's a > better choice
pix-opencv is developed by different people than Gem. i think it is good to keep the repositories (and user-management) separate. so: i'd rather not have pix-opencv be "part" of Gem.
but:
i agree that pix-opencv could be made more readily available to users. it might be a good idea to distribute it together with Gem-releases.
so:
the build-system needs little changes to build a pix_opencv found in extra/ (basically, uncomment the relevant lines at the end of extra/configure.ac and add a line to extra/Makefile.am)
we could then create a script that pulls in pix-opencv to extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
- is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
- pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a
do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2012-12-12 19:42, Antoine Villeret wrote: >> i've already tried to make a C++ external from the template but i >> never reach something which works so if you have a working template >> please let me know > > pix-opencv depends on external libraries, and afaik often needs > specific versions thereof. > i think it is a perfect candidate to *not* use a template Makefile but > instead use something more intelligent like autotools, scons, > cmake,...which reminds me that it already does use autoconf
>> and what about including it in Gem ? as it depends on it (and it >> may depends on very new feature such as ROI soon) i think it's a >> better choice > > pix-opencv is developed by different people than Gem. i think it is > good to keep the repositories (and user-management) separate. > so: i'd rather not have pix-opencv be "part" of Gem. > > but: > > i agree that pix-opencv could be made more readily available to users. > it might be a good idea to distribute it together with Gem-releases. > > so: > > the build-system needs little changes to build a pix_opencv found in > extra/ (basically, uncomment the relevant lines at the end of > extra/configure.ac and add a line to extra/Makefile.am) > > > > we could then create a script that pulls in pix-opencv to > extra/pix_opencv before the builds are actually started.
autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
- is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
- pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a
do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
2012/12/13 Hans-Christoph Steiner hans@at.or.at: > > On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 2012-12-12 19:42, Antoine Villeret wrote: >>> i've already tried to make a C++ external from the template but i >>> never reach something which works so if you have a working template >>> please let me know >> >> pix-opencv depends on external libraries, and afaik often needs >> specific versions thereof. >> i think it is a perfect candidate to *not* use a template Makefile but >> instead use something more intelligent like autotools, scons, >> cmake,...which reminds me that it already does use autoconf > >>> and what about including it in Gem ? as it depends on it (and it >>> may depends on very new feature such as ROI soon) i think it's a >>> better choice >> >> pix-opencv is developed by different people than Gem. i think it is >> good to keep the repositories (and user-management) separate. >> so: i'd rather not have pix-opencv be "part" of Gem. >> >> but: >> >> i agree that pix-opencv could be made more readily available to users. >> it might be a good idea to distribute it together with Gem-releases. >> >> so: >> >> the build-system needs little changes to build a pix_opencv found in >> extra/ (basically, uncomment the relevant lines at the end of >> extra/configure.ac and add a line to extra/Makefile.am) >> >> >> >> we could then create a script that pulls in pix-opencv to >> extra/pix_opencv before the builds are actually started. > > autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
I don't know anything about autotool and it looks like quite dark for me so if i can avoid another headache it's better :-)
> > As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. > > My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. > > The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: > > http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
I think we should ask Lluis for that with the current Makefile in the SVN man should have opencv >= 2.3 (some externals won't compile with previous OpenCV version) but there is not check about that I think and I can build with ./configure --with-pd=<PATH> --with-gem=<PATH> make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
but only tested on Ubuntu I don't know if it could build on other linux distro and even less on Mac OS X and Windows Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
- is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
- pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a
do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at:
On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >> >> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>> i've already tried to make a C++ external from the template but i >>>> never reach something which works so if you have a working template >>>> please let me know >>> >>> pix-opencv depends on external libraries, and afaik often needs >>> specific versions thereof. >>> i think it is a perfect candidate to *not* use a template Makefile but >>> instead use something more intelligent like autotools, scons, >>> cmake,...which reminds me that it already does use autoconf >> >>>> and what about including it in Gem ? as it depends on it (and it >>>> may depends on very new feature such as ROI soon) i think it's a >>>> better choice >>> >>> pix-opencv is developed by different people than Gem. i think it is >>> good to keep the repositories (and user-management) separate. >>> so: i'd rather not have pix-opencv be "part" of Gem. >>> >>> but: >>> >>> i agree that pix-opencv could be made more readily available to users. >>> it might be a good idea to distribute it together with Gem-releases. >>> >>> so: >>> >>> the build-system needs little changes to build a pix_opencv found in >>> extra/ (basically, uncomment the relevant lines at the end of >>> extra/configure.ac and add a line to extra/Makefile.am) >>> >>> >>> >>> we could then create a script that pulls in pix-opencv to >>> extra/pix_opencv before the builds are actually started. >> >> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. > > I don't know anything about autotool and it looks like quite dark for > me so if i can avoid another headache it's better :-) > > >> >> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >> >> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >> >> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >> >> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... > > I think we should ask Lluis for that > with the current Makefile in the SVN man should have opencv >= 2.3 > (some externals won't compile with previous OpenCV version) but there > is not check about that I think > and I can build with > ./configure --with-pd=<PATH> --with-gem=<PATH> > make
The Makefile equivalent of this is:
make PD_SRC=<PATH> GEM_SRC=<PATH>
Otherwise it'll look in the default installed locations for the headers.
> but only tested on Ubuntu > I don't know if it could build on other linux distro and even less on > Mac OS X and Windows > Should fixing that Makefile.in be a starting point to distrute the package ?
Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases.
.hc
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
- is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
- pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
hello,
I made an update today on pix_opencv with an improvement of pix_opencv_contours which is now a complete replacement of other pix_opencv_contours_* objects
and I sent a private mail to Lluis even if I found some old mails on this list by him and i never get any answer so maybe you can go ahead according to the "one week consensus" ?
there is actually one strange make rule, its for a custom blobtracker but I will change this as soon as i have time
merry chrismas to all
cheers
a
do it yourself http://antoine.villeret.free.fr
2012/12/13 Hans-Christoph Steiner hans@at.or.at: > > On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: > >> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>> >>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>> i've already tried to make a C++ external from the template but i >>>>> never reach something which works so if you have a working template >>>>> please let me know >>>> >>>> pix-opencv depends on external libraries, and afaik often needs >>>> specific versions thereof. >>>> i think it is a perfect candidate to *not* use a template Makefile but >>>> instead use something more intelligent like autotools, scons, >>>> cmake,...which reminds me that it already does use autoconf >>> >>>>> and what about including it in Gem ? as it depends on it (and it >>>>> may depends on very new feature such as ROI soon) i think it's a >>>>> better choice >>>> >>>> pix-opencv is developed by different people than Gem. i think it is >>>> good to keep the repositories (and user-management) separate. >>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>> >>>> but: >>>> >>>> i agree that pix-opencv could be made more readily available to users. >>>> it might be a good idea to distribute it together with Gem-releases. >>>> >>>> so: >>>> >>>> the build-system needs little changes to build a pix_opencv found in >>>> extra/ (basically, uncomment the relevant lines at the end of >>>> extra/configure.ac and add a line to extra/Makefile.am) >>>> >>>> >>>> >>>> we could then create a script that pulls in pix-opencv to >>>> extra/pix_opencv before the builds are actually started. >>> >>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >> >> I don't know anything about autotool and it looks like quite dark for >> me so if i can avoid another headache it's better :-) >> >> >>> >>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>> >>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>> >>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>> >>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >> >> I think we should ask Lluis for that >> with the current Makefile in the SVN man should have opencv >= 2.3 >> (some externals won't compile with previous OpenCV version) but there >> is not check about that I think >> and I can build with >> ./configure --with-pd=<PATH> --with-gem=<PATH> >> make > > The Makefile equivalent of this is: > > make PD_SRC=<PATH> GEM_SRC=<PATH> > > Otherwise it'll look in the default installed locations for the headers. > >> but only tested on Ubuntu >> I don't know if it could build on other linux distro and even less on >> Mac OS X and Windows >> Should fixing that Makefile.in be a starting point to distrute the package ? > > Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. > > .hc > >
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
- is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
- pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
.hc
On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote:
> hello, > > I made an update today on pix_opencv with an improvement of > pix_opencv_contours which is now a complete replacement of other > pix_opencv_contours_* objects > > and I sent a private mail to Lluis even if I found some old mails on > this list by him and i never get any answer > so maybe you can go ahead according to the "one week consensus" ? > > there is actually one strange make rule, its for a custom blobtracker > but I will change this as soon as i have time > > merry chrismas to all > > cheers > > a > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >> >> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >> >>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>> >>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>> i've already tried to make a C++ external from the template but i >>>>>> never reach something which works so if you have a working template >>>>>> please let me know >>>>> >>>>> pix-opencv depends on external libraries, and afaik often needs >>>>> specific versions thereof. >>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>> instead use something more intelligent like autotools, scons, >>>>> cmake,...which reminds me that it already does use autoconf >>>> >>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>> better choice >>>>> >>>>> pix-opencv is developed by different people than Gem. i think it is >>>>> good to keep the repositories (and user-management) separate. >>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>> >>>>> but: >>>>> >>>>> i agree that pix-opencv could be made more readily available to users. >>>>> it might be a good idea to distribute it together with Gem-releases. >>>>> >>>>> so: >>>>> >>>>> the build-system needs little changes to build a pix_opencv found in >>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>> >>>>> >>>>> >>>>> we could then create a script that pulls in pix-opencv to >>>>> extra/pix_opencv before the builds are actually started. >>>> >>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>> >>> I don't know anything about autotool and it looks like quite dark for >>> me so if i can avoid another headache it's better :-) >>> >>> >>>> >>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>> >>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>> >>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>> >>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>> >>> I think we should ask Lluis for that >>> with the current Makefile in the SVN man should have opencv >= 2.3 >>> (some externals won't compile with previous OpenCV version) but there >>> is not check about that I think >>> and I can build with >>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>> make >> >> The Makefile equivalent of this is: >> >> make PD_SRC=<PATH> GEM_SRC=<PATH> >> >> Otherwise it'll look in the default installed locations for the headers. >> >>> but only tested on Ubuntu >>> I don't know if it could build on other linux distro and even less on >>> Mac OS X and Windows >>> Should fixing that Makefile.in be a starting point to distrute the package ? >> >> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >> >> .hc >> >>
hi,
it's sounds great ! should I register somewhere ?
+ a -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at: > > Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors. > > The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
> > * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
> > * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
> > On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: > > make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource > > .hc > > On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: > >> hello, >> >> I made an update today on pix_opencv with an improvement of >> pix_opencv_contours which is now a complete replacement of other >> pix_opencv_contours_* objects >> >> and I sent a private mail to Lluis even if I found some old mails on >> this list by him and i never get any answer >> so maybe you can go ahead according to the "one week consensus" ? >> >> there is actually one strange make rule, its for a custom blobtracker >> but I will change this as soon as i have time >> >> merry chrismas to all >> >> cheers >> >> a >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>> >>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>> >>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>> >>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>> i've already tried to make a C++ external from the template but i >>>>>>> never reach something which works so if you have a working template >>>>>>> please let me know >>>>>> >>>>>> pix-opencv depends on external libraries, and afaik often needs >>>>>> specific versions thereof. >>>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>>> instead use something more intelligent like autotools, scons, >>>>>> cmake,...which reminds me that it already does use autoconf >>>>> >>>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>>> better choice >>>>>> >>>>>> pix-opencv is developed by different people than Gem. i think it is >>>>>> good to keep the repositories (and user-management) separate. >>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>> >>>>>> but: >>>>>> >>>>>> i agree that pix-opencv could be made more readily available to users. >>>>>> it might be a good idea to distribute it together with Gem-releases. >>>>>> >>>>>> so: >>>>>> >>>>>> the build-system needs little changes to build a pix_opencv found in >>>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>> >>>>>> >>>>>> >>>>>> we could then create a script that pulls in pix-opencv to >>>>>> extra/pix_opencv before the builds are actually started. >>>>> >>>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>>> >>>> I don't know anything about autotool and it looks like quite dark for >>>> me so if i can avoid another headache it's better :-) >>>> >>>> >>>>> >>>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>>> >>>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>>> >>>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>>> >>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>> >>>> I think we should ask Lluis for that >>>> with the current Makefile in the SVN man should have opencv >= 2.3 >>>> (some externals won't compile with previous OpenCV version) but there >>>> is not check about that I think >>>> and I can build with >>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>> make >>> >>> The Makefile equivalent of this is: >>> >>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>> >>> Otherwise it'll look in the default installed locations for the headers. >>> >>>> but only tested on Ubuntu >>>> I don't know if it could build on other linux distro and even less on >>>> Mac OS X and Windows >>>> Should fixing that Makefile.in be a starting point to distrute the package ? >>> >>> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >>> >>> .hc >>> >>> >
Post a request to pd-dev and send your ssh key, here are the details: http://puredata.info/docs/developer/PdLab
.hc
On 12/28/2012 07:20 AM, Antoine Villeret wrote:
hi,
it's sounds great ! should I register somewhere ?
a
do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
> hi, > > thansk for that, > > i had to change the CLAGS_linux variable (line 39) to : > CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv` > > to make it > but I don't know if I should or not push it to the SVN ? > > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >> >> Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors. >> >> The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too. > > really easy why not, but how ? > if I should make it myself I need a little more help... > the links on the page : http://puredata.info/dev/DebianPackagingStructure > are not broken but doesn't point to the right discussion... > anyway, I found the discussion and others but can't find anywhere a > good step by step howto build debian package > sorry, this will be my first debian package :-) > > >> >> * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is. > > I forgot this one... > I placed it in the examples/ folder for now > but working on optical flow externals is in my todo list (with gpu and opencl) > >> >> * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X? > > yes, most of recent and future externals take advantages of the new > C++ API of OpenCV 2.x > OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is > no Framework on the download page http://opencv.org/downloads.html > and a quick search lead to multiple posts over the internet on how to > build it by hand (which very easy since the new cmake system) > and also a precompiled package : > http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg > found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port > but it's obsolete > > ++ > a > >> >> On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: >> >> make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource >> >> .hc >> >> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >> >>> hello, >>> >>> I made an update today on pix_opencv with an improvement of >>> pix_opencv_contours which is now a complete replacement of other >>> pix_opencv_contours_* objects >>> >>> and I sent a private mail to Lluis even if I found some old mails on >>> this list by him and i never get any answer >>> so maybe you can go ahead according to the "one week consensus" ? >>> >>> there is actually one strange make rule, its for a custom blobtracker >>> but I will change this as soon as i have time >>> >>> merry chrismas to all >>> >>> cheers >>> >>> a >>> -- >>> do it yourself >>> http://antoine.villeret.free.fr >>> >>> >>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>> >>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>> >>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>> >>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>> >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>> i've already tried to make a C++ external from the template but i >>>>>>>> never reach something which works so if you have a working template >>>>>>>> please let me know >>>>>>> >>>>>>> pix-opencv depends on external libraries, and afaik often needs >>>>>>> specific versions thereof. >>>>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>>>> instead use something more intelligent like autotools, scons, >>>>>>> cmake,...which reminds me that it already does use autoconf >>>>>> >>>>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>>>> better choice >>>>>>> >>>>>>> pix-opencv is developed by different people than Gem. i think it is >>>>>>> good to keep the repositories (and user-management) separate. >>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>> >>>>>>> but: >>>>>>> >>>>>>> i agree that pix-opencv could be made more readily available to users. >>>>>>> it might be a good idea to distribute it together with Gem-releases. >>>>>>> >>>>>>> so: >>>>>>> >>>>>>> the build-system needs little changes to build a pix_opencv found in >>>>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>> >>>>>>> >>>>>>> >>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>> extra/pix_opencv before the builds are actually started. >>>>>> >>>>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>>>> >>>>> I don't know anything about autotool and it looks like quite dark for >>>>> me so if i can avoid another headache it's better :-) >>>>> >>>>> >>>>>> >>>>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>>>> >>>>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>>>> >>>>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>>>> >>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>>> >>>>> I think we should ask Lluis for that >>>>> with the current Makefile in the SVN man should have opencv >= 2.3 >>>>> (some externals won't compile with previous OpenCV version) but there >>>>> is not check about that I think >>>>> and I can build with >>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>> make >>>> >>>> The Makefile equivalent of this is: >>>> >>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>> >>>> Otherwise it'll look in the default installed locations for the headers. >>>> >>>>> but only tested on Ubuntu >>>>> I don't know if it could build on other linux distro and even less on >>>>> Mac OS X and Windows >>>>> Should fixing that Makefile.in be a starting point to distrute the package ? >>>> >>>> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >>>> >>>> .hc >>>> >>>> >>
ok cool but puredata.info seems to be down now... I'll try agan later
thanks
a -- do it yourself http://antoine.villeret.free.fr
2012/12/28 Hans-Christoph Steiner hans@at.or.at:
Post a request to pd-dev and send your ssh key, here are the details: http://puredata.info/docs/developer/PdLab
.hc
On 12/28/2012 07:20 AM, Antoine Villeret wrote:
hi,
it's sounds great ! should I register somewhere ?
a
do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at: > > What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations. > > .hc > > On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: > >> hi, >> >> thansk for that, >> >> i had to change the CLAGS_linux variable (line 39) to : >> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv` >> >> to make it >> but I don't know if I should or not push it to the SVN ? >> >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>> >>> Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors. >>> >>> The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too. >> >> really easy why not, but how ? >> if I should make it myself I need a little more help... >> the links on the page : http://puredata.info/dev/DebianPackagingStructure >> are not broken but doesn't point to the right discussion... >> anyway, I found the discussion and others but can't find anywhere a >> good step by step howto build debian package >> sorry, this will be my first debian package :-) >> >> >>> >>> * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is. >> >> I forgot this one... >> I placed it in the examples/ folder for now >> but working on optical flow externals is in my todo list (with gpu and opencl) >> >>> >>> * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X? >> >> yes, most of recent and future externals take advantages of the new >> C++ API of OpenCV 2.x >> OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is >> no Framework on the download page http://opencv.org/downloads.html >> and a quick search lead to multiple posts over the internet on how to >> build it by hand (which very easy since the new cmake system) >> and also a precompiled package : >> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >> found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port >> but it's obsolete >> >> ++ >> a >> >>> >>> On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: >>> >>> make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource >>> >>> .hc >>> >>> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >>> >>>> hello, >>>> >>>> I made an update today on pix_opencv with an improvement of >>>> pix_opencv_contours which is now a complete replacement of other >>>> pix_opencv_contours_* objects >>>> >>>> and I sent a private mail to Lluis even if I found some old mails on >>>> this list by him and i never get any answer >>>> so maybe you can go ahead according to the "one week consensus" ? >>>> >>>> there is actually one strange make rule, its for a custom blobtracker >>>> but I will change this as soon as i have time >>>> >>>> merry chrismas to all >>>> >>>> cheers >>>> >>>> a >>>> -- >>>> do it yourself >>>> http://antoine.villeret.free.fr >>>> >>>> >>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>> >>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>> >>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>> >>>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>>> >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>>> i've already tried to make a C++ external from the template but i >>>>>>>>> never reach something which works so if you have a working template >>>>>>>>> please let me know >>>>>>>> >>>>>>>> pix-opencv depends on external libraries, and afaik often needs >>>>>>>> specific versions thereof. >>>>>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>>>>> instead use something more intelligent like autotools, scons, >>>>>>>> cmake,...which reminds me that it already does use autoconf >>>>>>> >>>>>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>>>>> better choice >>>>>>>> >>>>>>>> pix-opencv is developed by different people than Gem. i think it is >>>>>>>> good to keep the repositories (and user-management) separate. >>>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>>> >>>>>>>> but: >>>>>>>> >>>>>>>> i agree that pix-opencv could be made more readily available to users. >>>>>>>> it might be a good idea to distribute it together with Gem-releases. >>>>>>>> >>>>>>>> so: >>>>>>>> >>>>>>>> the build-system needs little changes to build a pix_opencv found in >>>>>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>>> extra/pix_opencv before the builds are actually started. >>>>>>> >>>>>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>>>>> >>>>>> I don't know anything about autotool and it looks like quite dark for >>>>>> me so if i can avoid another headache it's better :-) >>>>>> >>>>>> >>>>>>> >>>>>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>>>>> >>>>>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>>>>> >>>>>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>>>>> >>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>>>> >>>>>> I think we should ask Lluis for that >>>>>> with the current Makefile in the SVN man should have opencv >= 2.3 >>>>>> (some externals won't compile with previous OpenCV version) but there >>>>>> is not check about that I think >>>>>> and I can build with >>>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>>> make >>>>> >>>>> The Makefile equivalent of this is: >>>>> >>>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>>> >>>>> Otherwise it'll look in the default installed locations for the headers. >>>>> >>>>>> but only tested on Ubuntu >>>>>> I don't know if it could build on other linux distro and even less on >>>>>> Mac OS X and Windows >>>>>> Should fixing that Makefile.in be a starting point to distrute the package ? >>>>> >>>>> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >>>>> >>>>> .hc >>>>> >>>>> >>> >
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed the Makefile to use pkg-config on all platforms. I don't know the protocol on editing the README, so I didn't touch it. It would make things easier for users if there was only one build system and the README only covered that. I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/ $ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole pix_opencv folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.info will include the 32-bit libraries, which is what you need for current versions of Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work for 64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile and layout, that it'll be trivially easy to make Debian packages for it. I can do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
hi,
thansk for that,
i had to change the CLAGS_linux variable (line 39) to : CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv`
to make it but I don't know if I should or not push it to the SVN ?
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at: > > Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors. > > The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
really easy why not, but how ? if I should make it myself I need a little more help... the links on the page : http://puredata.info/dev/DebianPackagingStructure are not broken but doesn't point to the right discussion... anyway, I found the discussion and others but can't find anywhere a good step by step howto build debian package sorry, this will be my first debian package :-)
> > * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
I forgot this one... I placed it in the examples/ folder for now but working on optical flow externals is in my todo list (with gpu and opencl)
> > * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
yes, most of recent and future externals take advantages of the new C++ API of OpenCV 2.x OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is no Framework on the download page http://opencv.org/downloads.html and a quick search lead to multiple posts over the internet on how to build it by hand (which very easy since the new cmake system) and also a precompiled package : http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port but it's obsolete
++ a
> > On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: > > make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource > > .hc > > On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: > >> hello, >> >> I made an update today on pix_opencv with an improvement of >> pix_opencv_contours which is now a complete replacement of other >> pix_opencv_contours_* objects >> >> and I sent a private mail to Lluis even if I found some old mails on >> this list by him and i never get any answer >> so maybe you can go ahead according to the "one week consensus" ? >> >> there is actually one strange make rule, its for a custom blobtracker >> but I will change this as soon as i have time >> >> merry chrismas to all >> >> cheers >> >> a >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>> >>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>> >>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>> >>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>> i've already tried to make a C++ external from the template but i >>>>>>> never reach something which works so if you have a working template >>>>>>> please let me know >>>>>> >>>>>> pix-opencv depends on external libraries, and afaik often needs >>>>>> specific versions thereof. >>>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>>> instead use something more intelligent like autotools, scons, >>>>>> cmake,...which reminds me that it already does use autoconf >>>>> >>>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>>> better choice >>>>>> >>>>>> pix-opencv is developed by different people than Gem. i think it is >>>>>> good to keep the repositories (and user-management) separate. >>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>> >>>>>> but: >>>>>> >>>>>> i agree that pix-opencv could be made more readily available to users. >>>>>> it might be a good idea to distribute it together with Gem-releases. >>>>>> >>>>>> so: >>>>>> >>>>>> the build-system needs little changes to build a pix_opencv found in >>>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>> >>>>>> >>>>>> >>>>>> we could then create a script that pulls in pix-opencv to >>>>>> extra/pix_opencv before the builds are actually started. >>>>> >>>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>>> >>>> I don't know anything about autotool and it looks like quite dark for >>>> me so if i can avoid another headache it's better :-) >>>> >>>> >>>>> >>>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>>> >>>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>>> >>>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>>> >>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>> >>>> I think we should ask Lluis for that >>>> with the current Makefile in the SVN man should have opencv >= 2.3 >>>> (some externals won't compile with previous OpenCV version) but there >>>> is not check about that I think >>>> and I can build with >>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>> make >>> >>> The Makefile equivalent of this is: >>> >>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>> >>> Otherwise it'll look in the default installed locations for the headers. >>> >>>> but only tested on Ubuntu >>>> I don't know if it could build on other linux distro and even less on >>>> Mac OS X and Windows >>>> Should fixing that Makefile.in be a starting point to distrute the package ? >>> >>> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >>> >>> .hc >>> >>> >
Hi Hans and all,
happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days...
I can log through SSH on pdlab computers (not tested all for now) but I have few more questions :
1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating lib) 2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be very old) ? Where should I work ?
sorry for those silly questions, but i don't want to break something...
a.
PS : this message should be signed with OpenPGP :-)
Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit :
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed the Makefile to use pkg-config on all platforms. I don't know the protocol on editing the README, so I didn't touch it. It would make things easier for users if there was only one build system and the README only covered that. I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/ $ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole pix_opencv folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.info will include the 32-bit libraries, which is what you need for current versions of Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work for 64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile and layout, that it'll be trivially easy to make Debian packages for it. I can do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
.hc
On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote:
> hi, > > thansk for that, > > i had to change the CLAGS_linux variable (line 39) to : > CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv` > > to make it > but I don't know if I should or not push it to the SVN ? > > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >> >> Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors. >> >> The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too. > > really easy why not, but how ? > if I should make it myself I need a little more help... > the links on the page : http://puredata.info/dev/DebianPackagingStructure > are not broken but doesn't point to the right discussion... > anyway, I found the discussion and others but can't find anywhere a > good step by step howto build debian package > sorry, this will be my first debian package :-) > > >> >> * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is. > > I forgot this one... > I placed it in the examples/ folder for now > but working on optical flow externals is in my todo list (with gpu and opencl) > >> >> * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X? > > yes, most of recent and future externals take advantages of the new > C++ API of OpenCV 2.x > OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is > no Framework on the download page http://opencv.org/downloads.html > and a quick search lead to multiple posts over the internet on how to > build it by hand (which very easy since the new cmake system) > and also a precompiled package : > http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg > found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port > but it's obsolete > > ++ > a > >> >> On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: >> >> make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource >> >> .hc >> >> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >> >>> hello, >>> >>> I made an update today on pix_opencv with an improvement of >>> pix_opencv_contours which is now a complete replacement of other >>> pix_opencv_contours_* objects >>> >>> and I sent a private mail to Lluis even if I found some old mails on >>> this list by him and i never get any answer >>> so maybe you can go ahead according to the "one week consensus" ? >>> >>> there is actually one strange make rule, its for a custom blobtracker >>> but I will change this as soon as i have time >>> >>> merry chrismas to all >>> >>> cheers >>> >>> a >>> -- >>> do it yourself >>> http://antoine.villeret.free.fr >>> >>> >>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>> >>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>> >>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>> >>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>> >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>> i've already tried to make a C++ external from the template but i >>>>>>>> never reach something which works so if you have a working template >>>>>>>> please let me know >>>>>>> >>>>>>> pix-opencv depends on external libraries, and afaik often needs >>>>>>> specific versions thereof. >>>>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>>>> instead use something more intelligent like autotools, scons, >>>>>>> cmake,...which reminds me that it already does use autoconf >>>>>> >>>>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>>>> better choice >>>>>>> >>>>>>> pix-opencv is developed by different people than Gem. i think it is >>>>>>> good to keep the repositories (and user-management) separate. >>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>> >>>>>>> but: >>>>>>> >>>>>>> i agree that pix-opencv could be made more readily available to users. >>>>>>> it might be a good idea to distribute it together with Gem-releases. >>>>>>> >>>>>>> so: >>>>>>> >>>>>>> the build-system needs little changes to build a pix_opencv found in >>>>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>> >>>>>>> >>>>>>> >>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>> extra/pix_opencv before the builds are actually started. >>>>>> >>>>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>>>> >>>>> I don't know anything about autotool and it looks like quite dark for >>>>> me so if i can avoid another headache it's better :-) >>>>> >>>>> >>>>>> >>>>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>>>> >>>>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>>>> >>>>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>>>> >>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>>> >>>>> I think we should ask Lluis for that >>>>> with the current Makefile in the SVN man should have opencv >= 2.3 >>>>> (some externals won't compile with previous OpenCV version) but there >>>>> is not check about that I think >>>>> and I can build with >>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>> make >>>> >>>> The Makefile equivalent of this is: >>>> >>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>> >>>> Otherwise it'll look in the default installed locations for the headers. >>>> >>>>> but only tested on Ubuntu >>>>> I don't know if it could build on other linux distro and even less on >>>>> Mac OS X and Windows >>>>> Should fixing that Makefile.in be a starting point to distrute the package ? >>>> >>>> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >>>> >>>> .hc >>>> >>>> >>
On 01/03/2013 03:10 PM, Antoine Villeret wrote:
Hi Hans and all,
happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days...
Definitely don't apologize for that, I wish I had been in the mountains :)
I can log through SSH on pdlab computers (not tested all for now) but I have few more questions :
1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating lib)
The pddev is pretty locked down, so I think you'd have to try to mess things up bad. The biggest worry would be filling up the disks on some of the VMs, since they are only 9 gigs. I think the Macs all have lots of disk.
2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be very old) ? Where should I work ?
Work wherever you'd like. I generally put svn checkouts in ~/code, use that, or ~/pure-data, or create your own folder if you want. I think the biggest rule would be don't mess with or delete files there that you didn't create.
sorry for those silly questions, but i don't want to break something...
Thanks for asking!
a.
PS : this message should be signed with OpenPGP :-)
Yup, its verified. :)
hc
Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit :
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed the Makefile to use pkg-config on all platforms. I don't know the protocol on editing the README, so I didn't touch it. It would make things easier for users if there was only one build system and the README only covered that. I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/ $ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole pix_opencv folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.info will include the 32-bit libraries, which is what you need for current versions of Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work for 64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile and layout, that it'll be trivially easy to make Debian packages for it. I can do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include -- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at: > > What installs the headers into /usr/local/include/Gem? The Gem package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations. > > .hc > > On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: > >> hi, >> >> thansk for that, >> >> i had to change the CLAGS_linux variable (line 39) to : >> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags opencv` >> >> to make it >> but I don't know if I should or not push it to the SVN ? >> >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>> >>> Ok, I committed a Makefile based on the Library Template. It does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors. >>> >>> The template Makefile will handle a lot of things automatically for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too. >> >> really easy why not, but how ? >> if I should make it myself I need a little more help... >> the links on the page : http://puredata.info/dev/DebianPackagingStructure >> are not broken but doesn't point to the right discussion... >> anyway, I found the discussion and others but can't find anywhere a >> good step by step howto build debian package >> sorry, this will be my first debian package :-) >> >> >>> >>> * is pix_opencv_opticalflow.pd an example or an abstraction? If its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is. >> >> I forgot this one... >> I placed it in the examples/ folder for now >> but working on optical flow externals is in my todo list (with gpu and opencl) >> >>> >>> * pix_opencv_blobtrack.cc seems to require opencv2, does that mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X? >> >> yes, most of recent and future externals take advantages of the new >> C++ API of OpenCV 2.x >> OpenCV 2 releases are distribute as a tarball for Linux/OSX, there is >> no Framework on the download page http://opencv.org/downloads.html >> and a quick search lead to multiple posts over the internet on how to >> build it by hand (which very easy since the new cmake system) >> and also a precompiled package : >> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >> found here : http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port >> but it's obsolete >> >> ++ >> a >> >>> >>> On Mac OS X, I was building against Pd-extended 0.43 since pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against: >>> >>> make PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource >>> >>> .hc >>> >>> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >>> >>>> hello, >>>> >>>> I made an update today on pix_opencv with an improvement of >>>> pix_opencv_contours which is now a complete replacement of other >>>> pix_opencv_contours_* objects >>>> >>>> and I sent a private mail to Lluis even if I found some old mails on >>>> this list by him and i never get any answer >>>> so maybe you can go ahead according to the "one week consensus" ? >>>> >>>> there is actually one strange make rule, its for a custom blobtracker >>>> but I will change this as soon as i have time >>>> >>>> merry chrismas to all >>>> >>>> cheers >>>> >>>> a >>>> -- >>>> do it yourself >>>> http://antoine.villeret.free.fr >>>> >>>> >>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>> >>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>> >>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>> >>>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>>> >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>>> i've already tried to make a C++ external from the template but i >>>>>>>>> never reach something which works so if you have a working template >>>>>>>>> please let me know >>>>>>>> >>>>>>>> pix-opencv depends on external libraries, and afaik often needs >>>>>>>> specific versions thereof. >>>>>>>> i think it is a perfect candidate to *not* use a template Makefile but >>>>>>>> instead use something more intelligent like autotools, scons, >>>>>>>> cmake,...which reminds me that it already does use autoconf >>>>>>> >>>>>>>>> and what about including it in Gem ? as it depends on it (and it >>>>>>>>> may depends on very new feature such as ROI soon) i think it's a >>>>>>>>> better choice >>>>>>>> >>>>>>>> pix-opencv is developed by different people than Gem. i think it is >>>>>>>> good to keep the repositories (and user-management) separate. >>>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>>> >>>>>>>> but: >>>>>>>> >>>>>>>> i agree that pix-opencv could be made more readily available to users. >>>>>>>> it might be a good idea to distribute it together with Gem-releases. >>>>>>>> >>>>>>>> so: >>>>>>>> >>>>>>>> the build-system needs little changes to build a pix_opencv found in >>>>>>>> extra/ (basically, uncomment the relevant lines at the end of >>>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>>> extra/pix_opencv before the builds are actually started. >>>>>>> >>>>>>> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary. >>>>>> >>>>>> I don't know anything about autotool and it looks like quite dark for >>>>>> me so if i can avoid another headache it's better :-) >>>>>> >>>>>> >>>>>>> >>>>>>> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant. >>>>>>> >>>>>>> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem. >>>>>>> >>>>>>> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned: >>>>>>> >>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>>>> >>>>>> I think we should ask Lluis for that >>>>>> with the current Makefile in the SVN man should have opencv >= 2.3 >>>>>> (some externals won't compile with previous OpenCV version) but there >>>>>> is not check about that I think >>>>>> and I can build with >>>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>>> make >>>>> >>>>> The Makefile equivalent of this is: >>>>> >>>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>>> >>>>> Otherwise it'll look in the default installed locations for the headers. >>>>> >>>>>> but only tested on Ubuntu >>>>>> I don't know if it could build on other linux distro and even less on >>>>>> Mac OS X and Windows >>>>>> Should fixing that Makefile.in be a starting point to distrute the package ? >>>>> >>>>> Let me know and i'll do it. Is Lluis on this list? Yes, I can include 'make osx_tarball' so its easy to make the tarball for releases. >>>>> >>>>> .hc >>>>> >>>>> >>> >
hi,
so i made a folder called "antoine" in the home of pddev on macosx105-i386 i build pix_opencv against latest Gem and pd vanilla 0.44 it doesn't compile with pd-extended (sorry for that)
i've made a tarball of the folder and put it here : http://puredata.info/Members/avilleret/pix_opencv_macosx_20130131/view how can i put it on the pix_opencv page ?
cheers
antoine
-- do it yourself http://antoine.villeret.free.fr
2013/1/3 Hans-Christoph Steiner hans@at.or.at
On 01/03/2013 03:10 PM, Antoine Villeret wrote:
Hi Hans and all,
happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days...
Definitely don't apologize for that, I wish I had been in the mountains :)
I can log through SSH on pdlab computers (not tested all for now) but I have few more questions :
1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating lib)
The pddev is pretty locked down, so I think you'd have to try to mess things up bad. The biggest worry would be filling up the disks on some of the VMs, since they are only 9 gigs. I think the Macs all have lots of disk.
2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be very old) ? Where should I work ?
Work wherever you'd like. I generally put svn checkouts in ~/code, use that, or ~/pure-data, or create your own folder if you want. I think the biggest rule would be don't mess with or delete files there that you didn't create.
sorry for those silly questions, but i don't want to break something...
Thanks for asking!
a.
PS : this message should be signed with OpenPGP :-)
Yup, its verified. :)
hc
Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit :
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed the
Makefile to use pkg-config on all platforms. I don't know the protocol on editing the README, so I didn't touch it. It would make things easier for users if there was only one build system and the README only covered that. I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make
PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/
$ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed
and embeds them in the folder. Then you can tarbz the whole pix_opencv folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.infowill include the 32-bit libraries, which is what you need for current
versions of Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work for 64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile and
layout, that it'll be trivially easy to make Debian packages for it. I can do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can
get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at:
Ah ok, makes sense. What about opencv2 on Mac OS X? How is that
handled?
.hc
On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote:
> the default make install command from git repo install gem into > /usr/local/include > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >> >> What installs the headers into /usr/local/include/Gem? The Gem
package in Debian/Ubuntu installs into /usr/include/Gem, so -I/usr/include/Gem needs to be there. If some standard installer installs into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add their custom Gem header install locations.
>> >> .hc >> >> On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: >> >>> hi, >>> >>> thansk for that, >>> >>> i had to change the CLAGS_linux variable (line 39) to : >>> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags
opencv`
>>> >>> to make it >>> but I don't know if I should or not push it to the SVN ? >>> >>> -- >>> do it yourself >>> http://antoine.villeret.free.fr >>> >>> >>> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>>> >>>> Ok, I committed a Makefile based on the Library Template. It
does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both gave a big dump of roughly the same errors.
>>>> >>>> The template Makefile will handle a lot of things automatically
for you, the trade-off is that its strict about certain things: every object must have a help patch, all example files must go into examples/, etc. The template Makefile is really easy to make a Debian package from too.
>>> >>> really easy why not, but how ? >>> if I should make it myself I need a little more help... >>> the links on the page :
http://puredata.info/dev/DebianPackagingStructure
>>> are not broken but doesn't point to the right discussion... >>> anyway, I found the discussion and others but can't find anywhere
a
>>> good step by step howto build debian package >>> sorry, this will be my first debian package :-) >>> >>> >>>> >>>> * is pix_opencv_opticalflow.pd an example or an abstraction? If
its an example, it should go into examples/ with of.frag. If its an abstraction, it should have a help patch. Or if its just a text patch, it can be left out of the Makefile and left as is.
>>> >>> I forgot this one... >>> I placed it in the examples/ folder for now >>> but working on optical flow externals is in my todo list (with
gpu and opencl)
>>> >>>> >>>> * pix_opencv_blobtrack.cc seems to require opencv2, does that
mean both opencv 1.2 and opencv 2.x need to be installed? Is there an OpenCV2 framework for Mac OS X?
>>> >>> yes, most of recent and future externals take advantages of the
new
>>> C++ API of OpenCV 2.x >>> OpenCV 2 releases are distribute as a tarball for Linux/OSX,
there is
>>> no Framework on the download page
http://opencv.org/downloads.html
>>> and a quick search lead to multiple posts over the internet on
how to
>>> build it by hand (which very easy since the new cmake system) >>> and also a precompiled package : >>> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >>> found here :
http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port
>>> but it's obsolete >>> >>> ++ >>> a >>> >>>> >>>> On Mac OS X, I was building against Pd-extended 0.43 since
pix_opencv uses some new Gem headers that aren't included in Pd-extended 0.42. The template Makefile automatically looks in Pd-extended if its in /Applications. If you want to choose which version of Pd-extende to build against:
>>>> >>>> make
PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
>>>> >>>> .hc >>>> >>>> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >>>> >>>>> hello, >>>>> >>>>> I made an update today on pix_opencv with an improvement of >>>>> pix_opencv_contours which is now a complete replacement of other >>>>> pix_opencv_contours_* objects >>>>> >>>>> and I sent a private mail to Lluis even if I found some old
mails on
>>>>> this list by him and i never get any answer >>>>> so maybe you can go ahead according to the "one week consensus"
?
>>>>> >>>>> there is actually one strange make rule, its for a custom
blobtracker
>>>>> but I will change this as soon as i have time >>>>> >>>>> merry chrismas to all >>>>> >>>>> cheers >>>>> >>>>> a >>>>> -- >>>>> do it yourself >>>>> http://antoine.villeret.free.fr >>>>> >>>>> >>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>> >>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>>> >>>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>>> >>>>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>>>> >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>> Hash: SHA1 >>>>>>>>> >>>>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>>>> i've already tried to make a C++ external from the
template but i
>>>>>>>>>> never reach something which works so if you have a working
template
>>>>>>>>>> please let me know >>>>>>>>> >>>>>>>>> pix-opencv depends on external libraries, and afaik often
needs
>>>>>>>>> specific versions thereof. >>>>>>>>> i think it is a perfect candidate to *not* use a template
Makefile but
>>>>>>>>> instead use something more intelligent like autotools,
scons,
>>>>>>>>> cmake,...which reminds me that it already does use autoconf >>>>>>>> >>>>>>>>>> and what about including it in Gem ? as it depends on it
(and it
>>>>>>>>>> may depends on very new feature such as ROI soon) i think
it's a
>>>>>>>>>> better choice >>>>>>>>> >>>>>>>>> pix-opencv is developed by different people than Gem. i
think it is
>>>>>>>>> good to keep the repositories (and user-management)
separate.
>>>>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>>>> >>>>>>>>> but: >>>>>>>>> >>>>>>>>> i agree that pix-opencv could be made more readily
available to users.
>>>>>>>>> it might be a good idea to distribute it together with
Gem-releases.
>>>>>>>>> >>>>>>>>> so: >>>>>>>>> >>>>>>>>> the build-system needs little changes to build a pix_opencv
found in
>>>>>>>>> extra/ (basically, uncomment the relevant lines at the end
of
>>>>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>>>> extra/pix_opencv before the builds are actually started. >>>>>>>> >>>>>>>> autotools are very useful for detecting platform differences
and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem. For the case you describe, that works well with the template Makefile. For an object that requires a specific library, add it to LDFLAGS. If that library not installed, it'll throw an error, which is what you want since the object requires that library. pix_opencv requires opencv, and does nothing without it, so no autotools necessary.
>>>>>>> >>>>>>> I don't know anything about autotool and it looks like quite
dark for
>>>>>>> me so if i can avoid another headache it's better :-) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> As for version differences, I generally find it way too much
work to support building against various versions of the API and just choose one and standardize on it. Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand. First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
>>>>>>>> >>>>>>>> My problem with autotools is that very few people know how
to modify it, so the build system then rots because its not maintained and other issues. I've seen this happen to a lot of autotools build systems in Pd projects over the years. For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools. This is one reason to not include every object in Gem.
>>>>>>>> >>>>>>>> The Makefile that's there is already quite close to working.
I'm happy to commit fixes to get it working if that's OK with the maintainers. I've committed to pix_opencv before. Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
>>>>>>>> >>>>>>>>
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
>>>>>>> >>>>>>> I think we should ask Lluis for that >>>>>>> with the current Makefile in the SVN man should have opencv
= 2.3
>>>>>>> (some externals won't compile with previous OpenCV version)
but there
>>>>>>> is not check about that I think >>>>>>> and I can build with >>>>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>>>> make >>>>>> >>>>>> The Makefile equivalent of this is: >>>>>> >>>>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>>>> >>>>>> Otherwise it'll look in the default installed locations for
the headers.
>>>>>> >>>>>>> but only tested on Ubuntu >>>>>>> I don't know if it could build on other linux distro and even
less on
>>>>>>> Mac OS X and Windows >>>>>>> Should fixing that Makefile.in be a starting point to
distrute the package ?
>>>>>> >>>>>> Let me know and i'll do it. Is Lluis on this list? Yes, I
can include 'make osx_tarball' so its easy to make the tarball for releases.
>>>>>> >>>>>> .hc >>>>>> >>>>>> >>>> >>
hey antoine
i just tried your build and it didnt work. i get:
/Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin: dlopen(/Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin, 10): Library not loaded: /sw/lib/libopencv_core.2.3.dylib Referenced from: /Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin Reason: no suitable image found. Did find: /sw/lib/libopencv_core.2.3.dylib: mach-o, but wrong architecture /usr/local/lib/libopencv_core.2.3.dylib: mach-o, but wrong architecture
because your dylibs are not embeded in the folder (mach-o, but wrong architecture errors are from my 64bit builds)
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole pix_opencv folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
so this didnt seem to work?
m
On Thu, Jan 31, 2013 at 11:49 AM, Antoine Villeret antoine.villeret@gmail.com wrote:
hi,
so i made a folder called "antoine" in the home of pddev on macosx105-i386 i build pix_opencv against latest Gem and pd vanilla 0.44 it doesn't compile with pd-extended (sorry for that)
i've made a tarball of the folder and put it here : http://puredata.info/Members/avilleret/pix_opencv_macosx_20130131/view how can i put it on the pix_opencv page ?
cheers
antoine
-- do it yourself http://antoine.villeret.free.fr
2013/1/3 Hans-Christoph Steiner hans@at.or.at
On 01/03/2013 03:10 PM, Antoine Villeret wrote:
Hi Hans and all,
happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days...
Definitely don't apologize for that, I wish I had been in the mountains :)
I can log through SSH on pdlab computers (not tested all for now) but I have few more questions :
1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating lib)
The pddev is pretty locked down, so I think you'd have to try to mess things up bad. The biggest worry would be filling up the disks on some of the VMs, since they are only 9 gigs. I think the Macs all have lots of disk.
2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be very old) ? Where should I work ?
Work wherever you'd like. I generally put svn checkouts in ~/code, use that, or ~/pure-data, or create your own folder if you want. I think the biggest rule would be don't mess with or delete files there that you didn't create.
sorry for those silly questions, but i don't want to break something...
Thanks for asking!
a.
PS : this message should be signed with OpenPGP :-)
Yup, its verified. :)
hc
Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit :
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed the Makefile to use pkg-config on all platforms. I don't know the protocol on editing the README, so I didn't touch it. It would make things easier for users if there was only one build system and the README only covered that. I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/ $ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole pix_opencv folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.info will include the 32-bit libraries, which is what you need for current versions of Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work for 64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile and layout, that it'll be trivially easy to make Debian packages for it. I can do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you can get access to the PdLab build machines, and I'm willing to install opencv 2.4.x on those machines. Basically, once everything is setup, you'll just need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
no idea, there wasn't any official opencv framework in the past, only some make by people who needs it but never maintained nor updated... so I think it still the case... people have to wait for someone who wants to make a framework, or to build it themselves but, are the packages available for Mac OS X through a package manager with automatic installation like in Debian ? if no, people have to build package by hand if I understood correctly so if they can build a pd package it will be very easy for them to build OpenCV 2 from lastest release which is I think a better idea than using an old and obsolete OpenCV Framework...
I don't have a Mac OS X machine under hand for now to test it but I think it's not really hard to make a step by step tutorial to make pix_opencv working on OS X with a tarball and some dev tool
-- do it yourself http://antoine.villeret.free.fr
2012/12/27 Hans-Christoph Steiner hans@at.or.at: > > Ah ok, makes sense. What about opencv2 on Mac OS X? How is that > handled? > > .hc > > On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote: > >> the default make install command from git repo install gem into >> /usr/local/include >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>> >>> What installs the headers into /usr/local/include/Gem? The Gem >>> package in Debian/Ubuntu installs into /usr/include/Gem, so >>> -I/usr/include/Gem needs to be there. If some standard installer installs >>> into /usr/local/include/Gem, then I'd keep -I /usr/local/include/Gem in >>> CFLAGS_linux, otherwise I'd leave it to people to edit the Makefile to add >>> their custom Gem header install locations. >>> >>> .hc >>> >>> On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: >>> >>>> hi, >>>> >>>> thansk for that, >>>> >>>> i had to change the CLAGS_linux variable (line 39) to : >>>> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags >>>> opencv` >>>> >>>> to make it >>>> but I don't know if I should or not push it to the SVN ? >>>> >>>> -- >>>> do it yourself >>>> http://antoine.villeret.free.fr >>>> >>>> >>>> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>>>> >>>>> Ok, I committed a Makefile based on the Library Template. It >>>>> does not build pix_opencv_contours.cc pix_opencv_matchshape.cc, they both >>>>> gave a big dump of roughly the same errors. >>>>> >>>>> The template Makefile will handle a lot of things automatically >>>>> for you, the trade-off is that its strict about certain things: every object >>>>> must have a help patch, all example files must go into examples/, etc. The >>>>> template Makefile is really easy to make a Debian package from too. >>>> >>>> really easy why not, but how ? >>>> if I should make it myself I need a little more help... >>>> the links on the page : >>>> http://puredata.info/dev/DebianPackagingStructure >>>> are not broken but doesn't point to the right discussion... >>>> anyway, I found the discussion and others but can't find anywhere >>>> a >>>> good step by step howto build debian package >>>> sorry, this will be my first debian package :-) >>>> >>>> >>>>> >>>>> * is pix_opencv_opticalflow.pd an example or an abstraction? If >>>>> its an example, it should go into examples/ with of.frag. If its an >>>>> abstraction, it should have a help patch. Or if its just a text patch, it >>>>> can be left out of the Makefile and left as is. >>>> >>>> I forgot this one... >>>> I placed it in the examples/ folder for now >>>> but working on optical flow externals is in my todo list (with >>>> gpu and opencl) >>>> >>>>> >>>>> * pix_opencv_blobtrack.cc seems to require opencv2, does that >>>>> mean both opencv 1.2 and opencv 2.x need to be installed? Is there an >>>>> OpenCV2 framework for Mac OS X? >>>> >>>> yes, most of recent and future externals take advantages of the >>>> new >>>> C++ API of OpenCV 2.x >>>> OpenCV 2 releases are distribute as a tarball for Linux/OSX, >>>> there is >>>> no Framework on the download page >>>> http://opencv.org/downloads.html >>>> and a quick search lead to multiple posts over the internet on >>>> how to >>>> build it by hand (which very easy since the new cmake system) >>>> and also a precompiled package : >>>> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >>>> found here : >>>> http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port >>>> but it's obsolete >>>> >>>> ++ >>>> a >>>> >>>>> >>>>> On Mac OS X, I was building against Pd-extended 0.43 since >>>>> pix_opencv uses some new Gem headers that aren't included in Pd-extended >>>>> 0.42. The template Makefile automatically looks in Pd-extended if its in >>>>> /Applications. If you want to choose which version of Pd-extende to build >>>>> against: >>>>> >>>>> make >>>>> PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource >>>>> >>>>> .hc >>>>> >>>>> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >>>>> >>>>>> hello, >>>>>> >>>>>> I made an update today on pix_opencv with an improvement of >>>>>> pix_opencv_contours which is now a complete replacement of >>>>>> other >>>>>> pix_opencv_contours_* objects >>>>>> >>>>>> and I sent a private mail to Lluis even if I found some old >>>>>> mails on >>>>>> this list by him and i never get any answer >>>>>> so maybe you can go ahead according to the "one week consensus" >>>>>> ? >>>>>> >>>>>> there is actually one strange make rule, its for a custom >>>>>> blobtracker >>>>>> but I will change this as soon as i have time >>>>>> >>>>>> merry chrismas to all >>>>>> >>>>>> cheers >>>>>> >>>>>> a >>>>>> -- >>>>>> do it yourself >>>>>> http://antoine.villeret.free.fr >>>>>> >>>>>> >>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>> >>>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>>>> >>>>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>>>> >>>>>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>>>>> >>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>> Hash: SHA1 >>>>>>>>>> >>>>>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>>>>> i've already tried to make a C++ external from the >>>>>>>>>>> template but i >>>>>>>>>>> never reach something which works so if you have a working >>>>>>>>>>> template >>>>>>>>>>> please let me know >>>>>>>>>> >>>>>>>>>> pix-opencv depends on external libraries, and afaik often >>>>>>>>>> needs >>>>>>>>>> specific versions thereof. >>>>>>>>>> i think it is a perfect candidate to *not* use a template >>>>>>>>>> Makefile but >>>>>>>>>> instead use something more intelligent like autotools, >>>>>>>>>> scons, >>>>>>>>>> cmake,...which reminds me that it already does use autoconf >>>>>>>>> >>>>>>>>>>> and what about including it in Gem ? as it depends on it >>>>>>>>>>> (and it >>>>>>>>>>> may depends on very new feature such as ROI soon) i think >>>>>>>>>>> it's a >>>>>>>>>>> better choice >>>>>>>>>> >>>>>>>>>> pix-opencv is developed by different people than Gem. i >>>>>>>>>> think it is >>>>>>>>>> good to keep the repositories (and user-management) >>>>>>>>>> separate. >>>>>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>>>>> >>>>>>>>>> but: >>>>>>>>>> >>>>>>>>>> i agree that pix-opencv could be made more readily >>>>>>>>>> available to users. >>>>>>>>>> it might be a good idea to distribute it together with >>>>>>>>>> Gem-releases. >>>>>>>>>> >>>>>>>>>> so: >>>>>>>>>> >>>>>>>>>> the build-system needs little changes to build a pix_opencv >>>>>>>>>> found in >>>>>>>>>> extra/ (basically, uncomment the relevant lines at the end >>>>>>>>>> of >>>>>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>>>>> extra/pix_opencv before the builds are actually started. >>>>>>>>> >>>>>>>>> autotools are very useful for detecting platform differences >>>>>>>>> and making the build system respond differently based on that, like handling >>>>>>>>> multiple optional dependencies like in Gem. For the case you describe, that >>>>>>>>> works well with the template Makefile. For an object that requires a >>>>>>>>> specific library, add it to LDFLAGS. If that library not installed, it'll >>>>>>>>> throw an error, which is what you want since the object requires that >>>>>>>>> library. pix_opencv requires opencv, and does nothing without it, so no >>>>>>>>> autotools necessary. >>>>>>>> >>>>>>>> I don't know anything about autotool and it looks like quite >>>>>>>> dark for >>>>>>>> me so if i can avoid another headache it's better :-) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> As for version differences, I generally find it way too much >>>>>>>>> work to support building against various versions of the API and just choose >>>>>>>>> one and standardize on it. Then, once this lib is widely distributed it >>>>>>>>> could be worth building against different versions of opencv if there is >>>>>>>>> demand. First get it out there for the majority of users, then deal with >>>>>>>>> any relevant edge cases, otherwise you are likely to spend lots of time >>>>>>>>> dealing with edge cases that might not really be relevant. >>>>>>>>> >>>>>>>>> My problem with autotools is that very few people know how >>>>>>>>> to modify it, so the build system then rots because its not maintained and >>>>>>>>> other issues. I've seen this happen to a lot of autotools build systems in >>>>>>>>> Pd projects over the years. For example, Gem's autotools setup has gotten >>>>>>>>> so complex, its almost impenetrable for me, and I've done a fair amount of >>>>>>>>> autotools. This is one reason to not include every object in Gem. >>>>>>>>> >>>>>>>>> The Makefile that's there is already quite close to working. >>>>>>>>> I'm happy to commit fixes to get it working if that's OK with the >>>>>>>>> maintainers. I've committed to pix_opencv before. Indeed I did this work >>>>>>>>> back in 2009 but sevy objected so it was reverted and abandoned: >>>>>>>>> >>>>>>>>> >>>>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op... >>>>>>>> >>>>>>>> I think we should ask Lluis for that >>>>>>>> with the current Makefile in the SVN man should have opencv >>>>>>>> >= 2.3 >>>>>>>> (some externals won't compile with previous OpenCV version) >>>>>>>> but there >>>>>>>> is not check about that I think >>>>>>>> and I can build with >>>>>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>>>>> make >>>>>>> >>>>>>> The Makefile equivalent of this is: >>>>>>> >>>>>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>>>>> >>>>>>> Otherwise it'll look in the default installed locations for >>>>>>> the headers. >>>>>>> >>>>>>>> but only tested on Ubuntu >>>>>>>> I don't know if it could build on other linux distro and even >>>>>>>> less on >>>>>>>> Mac OS X and Windows >>>>>>>> Should fixing that Makefile.in be a starting point to >>>>>>>> distrute the package ? >>>>>>> >>>>>>> Let me know and i'll do it. Is Lluis on this list? Yes, I >>>>>>> can include 'make osx_tarball' so its easy to make the tarball for releases. >>>>>>> >>>>>>> .hc >>>>>>> >>>>>>> >>>>> >>> >
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi,
thanks for the feedback,
I thought it was dynamically linked I tested it on a Mac OS 10.6.6 32bit machine where I installed OpenCV 2.3.3 with Fink and it works well
should I embbed the library in the mach-o ? if so, I don't how to...
but actually I made few changes after the build I've tested and before uploading so maybe I broke something...
I will give it a try tomorow
cheers
a
-- do it yourself http://antoine.villeret.free.fr
2013/2/7 me.grimm megrimm@gmail.com
hey antoine
i just tried your build and it didnt work. i get:
/Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin: dlopen(/Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin, 10): Library not loaded: /sw/lib/libopencv_core.2.3.dylib Referenced from: /Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin Reason: no suitable image found. Did find: /sw/lib/libopencv_core.2.3.dylib: mach-o, but wrong architecture /usr/local/lib/libopencv_core.2.3.dylib: mach-o, but wrong architecture
because your dylibs are not embeded in the folder (mach-o, but wrong architecture errors are from my 64bit builds)
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole
pix_opencv
folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
so this didnt seem to work?
m
On Thu, Jan 31, 2013 at 11:49 AM, Antoine Villeret antoine.villeret@gmail.com wrote:
hi,
so i made a folder called "antoine" in the home of pddev on
macosx105-i386
i build pix_opencv against latest Gem and pd vanilla 0.44 it doesn't compile with pd-extended (sorry for that)
i've made a tarball of the folder and put it here : http://puredata.info/Members/avilleret/pix_opencv_macosx_20130131/view how can i put it on the pix_opencv page ?
cheers
antoine
-- do it yourself http://antoine.villeret.free.fr
2013/1/3 Hans-Christoph Steiner hans@at.or.at
On 01/03/2013 03:10 PM, Antoine Villeret wrote:
Hi Hans and all,
happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days...
Definitely don't apologize for that, I wish I had been in the mountains
:)
I can log through SSH on pdlab computers (not tested all for now) but
I
have few more questions :
1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating
lib)
The pddev is pretty locked down, so I think you'd have to try to mess things up bad. The biggest worry would be filling up the disks on some of the VMs, since they are only 9 gigs. I think the Macs all have lots of disk.
2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be
very
old) ? Where should I work ?
Work wherever you'd like. I generally put svn checkouts in ~/code, use that, or ~/pure-data, or create your own folder if you want. I think the biggest rule would be don't mess with or delete files there that you didn't create.
sorry for those silly questions, but i don't want to break
something...
Thanks for asking!
a.
PS : this message should be signed with OpenPGP :-)
Yup, its verified. :)
hc
Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit :
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed
the
Makefile to use pkg-config on all platforms. I don't know the
protocol on
editing the README, so I didn't touch it. It would make things
easier for
users if there was only one build system and the README only covered
that.
I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make
PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/
$ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole
pix_opencv
folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.infowill include the 32-bit libraries, which is what you need for current
versions of
Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work
for
64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit
builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile
and
layout, that it'll be trivially easy to make Debian packages for it.
I can
do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
Hey Antoine,
If you are willing to maintain Mac OS X and/or Windows ports, you
can
get access to the PdLab build machines, and I'm willing to install
opencv
2.4.x on those machines. Basically, once everything is setup,
you'll just
need to make the builds on the various platforms by doing 'make'.
.hc
On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote:
> no idea, there wasn't any official opencv framework in the past,
only
> some make by people who needs it but never maintained nor
updated...
> so I think it still the case... > people have to wait for someone who wants to make a framework, or
to
> build it themselves > but, are the packages available for Mac OS X through a package > manager > with automatic installation like in Debian ? > if no, people have to build package by hand if I understood
correctly
> so if they can build a pd package it will be very easy for them to > build OpenCV 2 from lastest release > which is I think a better idea than using an old and obsolete
OpenCV
> Framework... > > I don't have a Mac OS X machine under hand for now to test it > but I think it's not really hard to make a step by step tutorial to > make pix_opencv working on OS X with a tarball and some dev tool > > -- > do it yourself > http://antoine.villeret.free.fr > > > 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >> >> Ah ok, makes sense. What about opencv2 on Mac OS X? How is that >> handled? >> >> .hc >> >> On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote: >> >>> the default make install command from git repo install gem into >>> /usr/local/include >>> -- >>> do it yourself >>> http://antoine.villeret.free.fr >>> >>> >>> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>>> >>>> What installs the headers into /usr/local/include/Gem? The Gem >>>> package in Debian/Ubuntu installs into /usr/include/Gem, so >>>> -I/usr/include/Gem needs to be there. If some standard
installer installs
>>>> into /usr/local/include/Gem, then I'd keep -I
/usr/local/include/Gem in
>>>> CFLAGS_linux, otherwise I'd leave it to people to edit the
Makefile to add
>>>> their custom Gem header install locations. >>>> >>>> .hc >>>> >>>> On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: >>>> >>>>> hi, >>>>> >>>>> thansk for that, >>>>> >>>>> i had to change the CLAGS_linux variable (line 39) to : >>>>> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags >>>>> opencv` >>>>> >>>>> to make it >>>>> but I don't know if I should or not push it to the SVN ? >>>>> >>>>> -- >>>>> do it yourself >>>>> http://antoine.villeret.free.fr >>>>> >>>>> >>>>> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>>>>> >>>>>> Ok, I committed a Makefile based on the Library Template. It >>>>>> does not build pix_opencv_contours.cc
pix_opencv_matchshape.cc, they both
>>>>>> gave a big dump of roughly the same errors. >>>>>> >>>>>> The template Makefile will handle a lot of things
automatically
>>>>>> for you, the trade-off is that its strict about certain
things: every object
>>>>>> must have a help patch, all example files must go into
examples/, etc. The
>>>>>> template Makefile is really easy to make a Debian package
from too.
>>>>> >>>>> really easy why not, but how ? >>>>> if I should make it myself I need a little more help... >>>>> the links on the page : >>>>> http://puredata.info/dev/DebianPackagingStructure >>>>> are not broken but doesn't point to the right discussion... >>>>> anyway, I found the discussion and others but can't find
anywhere
>>>>> a >>>>> good step by step howto build debian package >>>>> sorry, this will be my first debian package :-) >>>>> >>>>> >>>>>> >>>>>> * is pix_opencv_opticalflow.pd an example or an abstraction?
If
>>>>>> its an example, it should go into examples/ with of.frag. If
its an
>>>>>> abstraction, it should have a help patch. Or if its just a
text patch, it
>>>>>> can be left out of the Makefile and left as is. >>>>> >>>>> I forgot this one... >>>>> I placed it in the examples/ folder for now >>>>> but working on optical flow externals is in my todo list (with >>>>> gpu and opencl) >>>>> >>>>>> >>>>>> * pix_opencv_blobtrack.cc seems to require opencv2, does that >>>>>> mean both opencv 1.2 and opencv 2.x need to be installed? Is
there an
>>>>>> OpenCV2 framework for Mac OS X? >>>>> >>>>> yes, most of recent and future externals take advantages of the >>>>> new >>>>> C++ API of OpenCV 2.x >>>>> OpenCV 2 releases are distribute as a tarball for Linux/OSX, >>>>> there is >>>>> no Framework on the download page >>>>> http://opencv.org/downloads.html >>>>> and a quick search lead to multiple posts over the internet on >>>>> how to >>>>> build it by hand (which very easy since the new cmake system) >>>>> and also a precompiled package : >>>>> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >>>>> found here : >>>>> http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port >>>>> but it's obsolete >>>>> >>>>> ++ >>>>> a >>>>> >>>>>> >>>>>> On Mac OS X, I was building against Pd-extended 0.43 since >>>>>> pix_opencv uses some new Gem headers that aren't included in
Pd-extended
>>>>>> 0.42. The template Makefile automatically looks in
Pd-extended if its in
>>>>>> /Applications. If you want to choose which version of
Pd-extende to build
>>>>>> against: >>>>>> >>>>>> make >>>>>>
PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
>>>>>> >>>>>> .hc >>>>>> >>>>>> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >>>>>> >>>>>>> hello, >>>>>>> >>>>>>> I made an update today on pix_opencv with an improvement of >>>>>>> pix_opencv_contours which is now a complete replacement of >>>>>>> other >>>>>>> pix_opencv_contours_* objects >>>>>>> >>>>>>> and I sent a private mail to Lluis even if I found some old >>>>>>> mails on >>>>>>> this list by him and i never get any answer >>>>>>> so maybe you can go ahead according to the "one week
consensus"
>>>>>>> ? >>>>>>> >>>>>>> there is actually one strange make rule, its for a custom >>>>>>> blobtracker >>>>>>> but I will change this as soon as i have time >>>>>>> >>>>>>> merry chrismas to all >>>>>>> >>>>>>> cheers >>>>>>> >>>>>>> a >>>>>>> -- >>>>>>> do it yourself >>>>>>> http://antoine.villeret.free.fr >>>>>>> >>>>>>> >>>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>>> >>>>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>>>>> >>>>>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>>>>> >>>>>>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>>>>>> >>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>> Hash: SHA1 >>>>>>>>>>> >>>>>>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>>>>>> i've already tried to make a C++ external from the >>>>>>>>>>>> template but i >>>>>>>>>>>> never reach something which works so if you have a
working
>>>>>>>>>>>> template >>>>>>>>>>>> please let me know >>>>>>>>>>> >>>>>>>>>>> pix-opencv depends on external libraries, and afaik often >>>>>>>>>>> needs >>>>>>>>>>> specific versions thereof. >>>>>>>>>>> i think it is a perfect candidate to *not* use a template >>>>>>>>>>> Makefile but >>>>>>>>>>> instead use something more intelligent like autotools, >>>>>>>>>>> scons, >>>>>>>>>>> cmake,...which reminds me that it already does use
autoconf
>>>>>>>>>> >>>>>>>>>>>> and what about including it in Gem ? as it depends on it >>>>>>>>>>>> (and it >>>>>>>>>>>> may depends on very new feature such as ROI soon) i
think
>>>>>>>>>>>> it's a >>>>>>>>>>>> better choice >>>>>>>>>>> >>>>>>>>>>> pix-opencv is developed by different people than Gem. i >>>>>>>>>>> think it is >>>>>>>>>>> good to keep the repositories (and user-management) >>>>>>>>>>> separate. >>>>>>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>>>>>> >>>>>>>>>>> but: >>>>>>>>>>> >>>>>>>>>>> i agree that pix-opencv could be made more readily >>>>>>>>>>> available to users. >>>>>>>>>>> it might be a good idea to distribute it together with >>>>>>>>>>> Gem-releases. >>>>>>>>>>> >>>>>>>>>>> so: >>>>>>>>>>> >>>>>>>>>>> the build-system needs little changes to build a
pix_opencv
>>>>>>>>>>> found in >>>>>>>>>>> extra/ (basically, uncomment the relevant lines at the
end
>>>>>>>>>>> of >>>>>>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>>>>>> extra/pix_opencv before the builds are actually started. >>>>>>>>>> >>>>>>>>>> autotools are very useful for detecting platform
differences
>>>>>>>>>> and making the build system respond differently based on
that, like handling
>>>>>>>>>> multiple optional dependencies like in Gem. For the case
you describe, that
>>>>>>>>>> works well with the template Makefile. For an object
that requires a
>>>>>>>>>> specific library, add it to LDFLAGS. If that library not
installed, it'll
>>>>>>>>>> throw an error, which is what you want since the object
requires that
>>>>>>>>>> library. pix_opencv requires opencv, and does nothing
without it, so no
>>>>>>>>>> autotools necessary. >>>>>>>>> >>>>>>>>> I don't know anything about autotool and it looks like
quite
>>>>>>>>> dark for >>>>>>>>> me so if i can avoid another headache it's better :-) >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As for version differences, I generally find it way too
much
>>>>>>>>>> work to support building against various versions of the
API and just choose
>>>>>>>>>> one and standardize on it. Then, once this lib is widely
distributed it
>>>>>>>>>> could be worth building against different versions of
opencv if there is
>>>>>>>>>> demand. First get it out there for the majority of
users, then deal with
>>>>>>>>>> any relevant edge cases, otherwise you are likely to
spend lots of time
>>>>>>>>>> dealing with edge cases that might not really be relevant. >>>>>>>>>> >>>>>>>>>> My problem with autotools is that very few people know how >>>>>>>>>> to modify it, so the build system then rots because its
not maintained and
>>>>>>>>>> other issues. I've seen this happen to a lot of
autotools build systems in
>>>>>>>>>> Pd projects over the years. For example, Gem's autotools
setup has gotten
>>>>>>>>>> so complex, its almost impenetrable for me, and I've done
a fair amount of
>>>>>>>>>> autotools. This is one reason to not include every
object in Gem.
>>>>>>>>>> >>>>>>>>>> The Makefile that's there is already quite close to
working.
>>>>>>>>>> I'm happy to commit fixes to get it working if that's OK
with the
>>>>>>>>>> maintainers. I've committed to pix_opencv before.
Indeed I did this work
>>>>>>>>>> back in 2009 but sevy objected so it was reverted and
abandoned:
>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
>>>>>>>>> >>>>>>>>> I think we should ask Lluis for that >>>>>>>>> with the current Makefile in the SVN man should have opencv >>>>>>>>> >= 2.3 >>>>>>>>> (some externals won't compile with previous OpenCV version) >>>>>>>>> but there >>>>>>>>> is not check about that I think >>>>>>>>> and I can build with >>>>>>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>>>>>> make >>>>>>>> >>>>>>>> The Makefile equivalent of this is: >>>>>>>> >>>>>>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>>>>>> >>>>>>>> Otherwise it'll look in the default installed locations for >>>>>>>> the headers. >>>>>>>> >>>>>>>>> but only tested on Ubuntu >>>>>>>>> I don't know if it could build on other linux distro and
even
>>>>>>>>> less on >>>>>>>>> Mac OS X and Windows >>>>>>>>> Should fixing that Makefile.in be a starting point to >>>>>>>>> distrute the package ? >>>>>>>> >>>>>>>> Let me know and i'll do it. Is Lluis on this list? Yes, I >>>>>>>> can include 'make osx_tarball' so its easy to make the
tarball for releases.
>>>>>>>> >>>>>>>> .hc >>>>>>>> >>>>>>>> >>>>>> >>>> >>
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
Antoine,
You can embed the libraries using the ./embed-MacOSX-dependencies.sh script, just run it like this:
cd pix_opencv ./embed-MacOSX-dependencies.sh .
Then it'll copy all of the libs from Fink into the pix_opencv folder, then that folder can be tarred up and its the library. I also automated this using our jenkins server, so whenever a new commit is pushed, it should automatically build the full library for Mac OS X powerpc, i386, and x86_64. Here are the most recent builds:
http://autobuild.puredata.info/auto-build/2013-02-07/
And here is the jenkins job: https://macosx105-i386.pdlab.puredata.info/job/pix_opencv
.hc
On 02/07/2013 07:07 PM, Antoine Villeret wrote:
hi,
thanks for the feedback,
I thought it was dynamically linked I tested it on a Mac OS 10.6.6 32bit machine where I installed OpenCV 2.3.3 with Fink and it works well
should I embbed the library in the mach-o ? if so, I don't how to...
but actually I made few changes after the build I've tested and before uploading so maybe I broke something...
I will give it a try tomorow
cheers
a
-- do it yourself http://antoine.villeret.free.fr
2013/2/7 me.grimm megrimm@gmail.com
hey antoine
i just tried your build and it didnt work. i get:
/Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin: dlopen(/Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin, 10): Library not loaded: /sw/lib/libopencv_core.2.3.dylib Referenced from: /Users/megrimm/Desktop/pix_opencv/pix_opencv_athreshold.pd_darwin Reason: no suitable image found. Did find: /sw/lib/libopencv_core.2.3.dylib: mach-o, but wrong architecture /usr/local/lib/libopencv_core.2.3.dylib: mach-o, but wrong architecture
because your dylibs are not embeded in the folder (mach-o, but wrong architecture errors are from my 64bit builds)
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole
pix_opencv
folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
so this didnt seem to work?
m
On Thu, Jan 31, 2013 at 11:49 AM, Antoine Villeret antoine.villeret@gmail.com wrote:
hi,
so i made a folder called "antoine" in the home of pddev on
macosx105-i386
i build pix_opencv against latest Gem and pd vanilla 0.44 it doesn't compile with pd-extended (sorry for that)
i've made a tarball of the folder and put it here : http://puredata.info/Members/avilleret/pix_opencv_macosx_20130131/view how can i put it on the pix_opencv page ?
cheers
antoine
-- do it yourself http://antoine.villeret.free.fr
2013/1/3 Hans-Christoph Steiner hans@at.or.at
On 01/03/2013 03:10 PM, Antoine Villeret wrote:
Hi Hans and all,
happy new year and thanks for your work
sorry for the delayed answer, I was far away from Internet in the mountain for few days...
Definitely don't apologize for that, I wish I had been in the mountains
:)
I can log through SSH on pdlab computers (not tested all for now) but
I
have few more questions :
1- What can I do and (more important) what should I never do on those machines (particularly about SVN checkout and installing / updating
lib)
The pddev is pretty locked down, so I think you'd have to try to mess things up bad. The biggest worry would be filling up the disks on some of the VMs, since they are only 9 gigs. I think the Macs all have lots of disk.
2- There is no "pix_opencv" folder in the pddev home (on macosx105-i386.pdlab.puredata.info) where could I find the up-to-date folder ? should I cd to /Users/pddev/pure-data/trunk/externals/pix_opencv (this seems to be
very
old) ? Where should I work ?
Work wherever you'd like. I generally put svn checkouts in ~/code, use that, or ~/pure-data, or create your own folder if you want. I think the biggest rule would be don't mess with or delete files there that you didn't create.
sorry for those silly questions, but i don't want to break
something...
Thanks for asking!
a.
PS : this message should be signed with OpenPGP :-)
Yup, its verified. :)
hc
Le 31/12/2012 18:28, Hans-Christoph Steiner a écrit :
Hey Antoine,
So I installed OpenCV 2.3.1 on the PdLab Macs using Fink, and fixed
the
Makefile to use pkg-config on all platforms. I don't know the
protocol on
editing the README, so I didn't touch it. It would make things
easier for
users if there was only one build system and the README only covered
that.
I'll leave that to you. Here's how to make a build on Mac OS X:
$ . /sw/bin/init.sh (load Fink for other libs like opencv) $ cd pix_opencv $ make
PD_PATH=/Users/pd/auto-build/pd-extended/packages/darwin_app/build/Pd-0.43.4-extended-20121231.app/Contents/Resources/
$ ./embed-MacOSX-dependencies.sh .
./embed-MacOSX-dependencies.sh finds all the dynamic libraries needed and embeds them in the folder. Then you can tarbz the whole
pix_opencv
folder, and that's the installable library. Just drop that into ~/Library/Pd or /Library/Pd.
For the PdLab Macs, building on macosx105-i386.pdlab.puredata.infowill include the 32-bit libraries, which is what you need for current
versions of
Pd-extended for Mac OS X. Gem included in Pd-extended doesn't work
for
64-bit (Gem master does at this point, I think). Building on macosx106-x86_64 (chaos.medien.uni-weimar.de) will make 64-bit
builds.
For someone to build this on their own machine, they'll need to do:
fink install opencv-dev
On a related note, if you stick with the Library Template Makefile
and
layout, that it'll be trivially easy to make Debian packages for it.
I can
do that too, or leave it to you.
.hc
On Dec 27, 2012, at 3:36 PM, Hans-Christoph Steiner wrote:
> > Hey Antoine, > > If you are willing to maintain Mac OS X and/or Windows ports, you
can
> get access to the PdLab build machines, and I'm willing to install
opencv
> 2.4.x on those machines. Basically, once everything is setup,
you'll just
> need to make the builds on the various platforms by doing 'make'. > > .hc > > On Dec 27, 2012, at 10:35 AM, Antoine Villeret wrote: > >> no idea, there wasn't any official opencv framework in the past,
only
>> some make by people who needs it but never maintained nor
updated...
>> so I think it still the case... >> people have to wait for someone who wants to make a framework, or
to
>> build it themselves >> but, are the packages available for Mac OS X through a package >> manager >> with automatic installation like in Debian ? >> if no, people have to build package by hand if I understood
correctly
>> so if they can build a pd package it will be very easy for them to >> build OpenCV 2 from lastest release >> which is I think a better idea than using an old and obsolete
OpenCV
>> Framework... >> >> I don't have a Mac OS X machine under hand for now to test it >> but I think it's not really hard to make a step by step tutorial to >> make pix_opencv working on OS X with a tarball and some dev tool >> >> -- >> do it yourself >> http://antoine.villeret.free.fr >> >> >> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>> >>> Ah ok, makes sense. What about opencv2 on Mac OS X? How is that >>> handled? >>> >>> .hc >>> >>> On Dec 27, 2012, at 10:03 AM, Antoine Villeret wrote: >>> >>>> the default make install command from git repo install gem into >>>> /usr/local/include >>>> -- >>>> do it yourself >>>> http://antoine.villeret.free.fr >>>> >>>> >>>> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>>>> >>>>> What installs the headers into /usr/local/include/Gem? The Gem >>>>> package in Debian/Ubuntu installs into /usr/include/Gem, so >>>>> -I/usr/include/Gem needs to be there. If some standard
installer installs
>>>>> into /usr/local/include/Gem, then I'd keep -I
/usr/local/include/Gem in
>>>>> CFLAGS_linux, otherwise I'd leave it to people to edit the
Makefile to add
>>>>> their custom Gem header install locations. >>>>> >>>>> .hc >>>>> >>>>> On Dec 27, 2012, at 9:30 AM, Antoine Villeret wrote: >>>>> >>>>>> hi, >>>>>> >>>>>> thansk for that, >>>>>> >>>>>> i had to change the CLAGS_linux variable (line 39) to : >>>>>> CFLAGS_linux = -I/usr/local/include/Gem `pkg-config --cflags >>>>>> opencv` >>>>>> >>>>>> to make it >>>>>> but I don't know if I should or not push it to the SVN ? >>>>>> >>>>>> -- >>>>>> do it yourself >>>>>> http://antoine.villeret.free.fr >>>>>> >>>>>> >>>>>> 2012/12/27 Hans-Christoph Steiner hans@at.or.at: >>>>>>> >>>>>>> Ok, I committed a Makefile based on the Library Template. It >>>>>>> does not build pix_opencv_contours.cc
pix_opencv_matchshape.cc, they both
>>>>>>> gave a big dump of roughly the same errors. >>>>>>> >>>>>>> The template Makefile will handle a lot of things
automatically
>>>>>>> for you, the trade-off is that its strict about certain
things: every object
>>>>>>> must have a help patch, all example files must go into
examples/, etc. The
>>>>>>> template Makefile is really easy to make a Debian package
from too.
>>>>>> >>>>>> really easy why not, but how ? >>>>>> if I should make it myself I need a little more help... >>>>>> the links on the page : >>>>>> http://puredata.info/dev/DebianPackagingStructure >>>>>> are not broken but doesn't point to the right discussion... >>>>>> anyway, I found the discussion and others but can't find
anywhere
>>>>>> a >>>>>> good step by step howto build debian package >>>>>> sorry, this will be my first debian package :-) >>>>>> >>>>>> >>>>>>> >>>>>>> * is pix_opencv_opticalflow.pd an example or an abstraction?
If
>>>>>>> its an example, it should go into examples/ with of.frag. If
its an
>>>>>>> abstraction, it should have a help patch. Or if its just a
text patch, it
>>>>>>> can be left out of the Makefile and left as is. >>>>>> >>>>>> I forgot this one... >>>>>> I placed it in the examples/ folder for now >>>>>> but working on optical flow externals is in my todo list (with >>>>>> gpu and opencl) >>>>>> >>>>>>> >>>>>>> * pix_opencv_blobtrack.cc seems to require opencv2, does that >>>>>>> mean both opencv 1.2 and opencv 2.x need to be installed? Is
there an
>>>>>>> OpenCV2 framework for Mac OS X? >>>>>> >>>>>> yes, most of recent and future externals take advantages of the >>>>>> new >>>>>> C++ API of OpenCV 2.x >>>>>> OpenCV 2 releases are distribute as a tarball for Linux/OSX, >>>>>> there is >>>>>> no Framework on the download page >>>>>> http://opencv.org/downloads.html >>>>>> and a quick search lead to multiple posts over the internet on >>>>>> how to >>>>>> build it by hand (which very easy since the new cmake system) >>>>>> and also a precompiled package : >>>>>> http://vislab.cs.vt.edu/~vislab/wiki/images/4/44/OpenCV2.0.dmg >>>>>> found here : >>>>>> http://opencv.willowgarage.com/wiki/Mac_OS_X_OpenCV_Port >>>>>> but it's obsolete >>>>>> >>>>>> ++ >>>>>> a >>>>>> >>>>>>> >>>>>>> On Mac OS X, I was building against Pd-extended 0.43 since >>>>>>> pix_opencv uses some new Gem headers that aren't included in
Pd-extended
>>>>>>> 0.42. The template Makefile automatically looks in
Pd-extended if its in
>>>>>>> /Applications. If you want to choose which version of
Pd-extende to build
>>>>>>> against: >>>>>>> >>>>>>> make >>>>>>>
PD_PATH=/Applications/Pd-0.43.4-extended-20121223.app/Contents/Resource
>>>>>>> >>>>>>> .hc >>>>>>> >>>>>>> On Dec 26, 2012, at 3:11 PM, Antoine Villeret wrote: >>>>>>> >>>>>>>> hello, >>>>>>>> >>>>>>>> I made an update today on pix_opencv with an improvement of >>>>>>>> pix_opencv_contours which is now a complete replacement of >>>>>>>> other >>>>>>>> pix_opencv_contours_* objects >>>>>>>> >>>>>>>> and I sent a private mail to Lluis even if I found some old >>>>>>>> mails on >>>>>>>> this list by him and i never get any answer >>>>>>>> so maybe you can go ahead according to the "one week
consensus"
>>>>>>>> ? >>>>>>>> >>>>>>>> there is actually one strange make rule, its for a custom >>>>>>>> blobtracker >>>>>>>> but I will change this as soon as i have time >>>>>>>> >>>>>>>> merry chrismas to all >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>> a >>>>>>>> -- >>>>>>>> do it yourself >>>>>>>> http://antoine.villeret.free.fr >>>>>>>> >>>>>>>> >>>>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>>>> >>>>>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>>>>>> >>>>>>>>>> 2012/12/13 Hans-Christoph Steiner hans@at.or.at: >>>>>>>>>>> >>>>>>>>>>> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote: >>>>>>>>>>> >>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>>> Hash: SHA1 >>>>>>>>>>>> >>>>>>>>>>>> On 2012-12-12 19:42, Antoine Villeret wrote: >>>>>>>>>>>>> i've already tried to make a C++ external from the >>>>>>>>>>>>> template but i >>>>>>>>>>>>> never reach something which works so if you have a
working
>>>>>>>>>>>>> template >>>>>>>>>>>>> please let me know >>>>>>>>>>>> >>>>>>>>>>>> pix-opencv depends on external libraries, and afaik often >>>>>>>>>>>> needs >>>>>>>>>>>> specific versions thereof. >>>>>>>>>>>> i think it is a perfect candidate to *not* use a template >>>>>>>>>>>> Makefile but >>>>>>>>>>>> instead use something more intelligent like autotools, >>>>>>>>>>>> scons, >>>>>>>>>>>> cmake,...which reminds me that it already does use
autoconf
>>>>>>>>>>> >>>>>>>>>>>>> and what about including it in Gem ? as it depends on it >>>>>>>>>>>>> (and it >>>>>>>>>>>>> may depends on very new feature such as ROI soon) i
think
>>>>>>>>>>>>> it's a >>>>>>>>>>>>> better choice >>>>>>>>>>>> >>>>>>>>>>>> pix-opencv is developed by different people than Gem. i >>>>>>>>>>>> think it is >>>>>>>>>>>> good to keep the repositories (and user-management) >>>>>>>>>>>> separate. >>>>>>>>>>>> so: i'd rather not have pix-opencv be "part" of Gem. >>>>>>>>>>>> >>>>>>>>>>>> but: >>>>>>>>>>>> >>>>>>>>>>>> i agree that pix-opencv could be made more readily >>>>>>>>>>>> available to users. >>>>>>>>>>>> it might be a good idea to distribute it together with >>>>>>>>>>>> Gem-releases. >>>>>>>>>>>> >>>>>>>>>>>> so: >>>>>>>>>>>> >>>>>>>>>>>> the build-system needs little changes to build a
pix_opencv
>>>>>>>>>>>> found in >>>>>>>>>>>> extra/ (basically, uncomment the relevant lines at the
end
>>>>>>>>>>>> of >>>>>>>>>>>> extra/configure.ac and add a line to extra/Makefile.am) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> we could then create a script that pulls in pix-opencv to >>>>>>>>>>>> extra/pix_opencv before the builds are actually started. >>>>>>>>>>> >>>>>>>>>>> autotools are very useful for detecting platform
differences
>>>>>>>>>>> and making the build system respond differently based on
that, like handling
>>>>>>>>>>> multiple optional dependencies like in Gem. For the case
you describe, that
>>>>>>>>>>> works well with the template Makefile. For an object
that requires a
>>>>>>>>>>> specific library, add it to LDFLAGS. If that library not
installed, it'll
>>>>>>>>>>> throw an error, which is what you want since the object
requires that
>>>>>>>>>>> library. pix_opencv requires opencv, and does nothing
without it, so no
>>>>>>>>>>> autotools necessary. >>>>>>>>>> >>>>>>>>>> I don't know anything about autotool and it looks like
quite
>>>>>>>>>> dark for >>>>>>>>>> me so if i can avoid another headache it's better :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As for version differences, I generally find it way too
much
>>>>>>>>>>> work to support building against various versions of the
API and just choose
>>>>>>>>>>> one and standardize on it. Then, once this lib is widely
distributed it
>>>>>>>>>>> could be worth building against different versions of
opencv if there is
>>>>>>>>>>> demand. First get it out there for the majority of
users, then deal with
>>>>>>>>>>> any relevant edge cases, otherwise you are likely to
spend lots of time
>>>>>>>>>>> dealing with edge cases that might not really be relevant. >>>>>>>>>>> >>>>>>>>>>> My problem with autotools is that very few people know how >>>>>>>>>>> to modify it, so the build system then rots because its
not maintained and
>>>>>>>>>>> other issues. I've seen this happen to a lot of
autotools build systems in
>>>>>>>>>>> Pd projects over the years. For example, Gem's autotools
setup has gotten
>>>>>>>>>>> so complex, its almost impenetrable for me, and I've done
a fair amount of
>>>>>>>>>>> autotools. This is one reason to not include every
object in Gem.
>>>>>>>>>>> >>>>>>>>>>> The Makefile that's there is already quite close to
working.
>>>>>>>>>>> I'm happy to commit fixes to get it working if that's OK
with the
>>>>>>>>>>> maintainers. I've committed to pix_opencv before.
Indeed I did this work
>>>>>>>>>>> back in 2009 but sevy objected so it was reverted and
abandoned:
>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_op...
>>>>>>>>>> >>>>>>>>>> I think we should ask Lluis for that >>>>>>>>>> with the current Makefile in the SVN man should have opencv >>>>>>>>>>> = 2.3 >>>>>>>>>> (some externals won't compile with previous OpenCV version) >>>>>>>>>> but there >>>>>>>>>> is not check about that I think >>>>>>>>>> and I can build with >>>>>>>>>> ./configure --with-pd=<PATH> --with-gem=<PATH> >>>>>>>>>> make >>>>>>>>> >>>>>>>>> The Makefile equivalent of this is: >>>>>>>>> >>>>>>>>> make PD_SRC=<PATH> GEM_SRC=<PATH> >>>>>>>>> >>>>>>>>> Otherwise it'll look in the default installed locations for >>>>>>>>> the headers. >>>>>>>>> >>>>>>>>>> but only tested on Ubuntu >>>>>>>>>> I don't know if it could build on other linux distro and
even
>>>>>>>>>> less on >>>>>>>>>> Mac OS X and Windows >>>>>>>>>> Should fixing that Makefile.in be a starting point to >>>>>>>>>> distrute the package ? >>>>>>>>> >>>>>>>>> Let me know and i'll do it. Is Lluis on this list? Yes, I >>>>>>>>> can include 'make osx_tarball' so its easy to make the
tarball for releases.
>>>>>>>>> >>>>>>>>> .hc >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
On 02/08/2013 01:07 AM, Antoine Villeret wrote:
hi,
thanks for the feedback,
I thought it was dynamically linked I tested it on a Mac OS 10.6.6 32bit machine where I installed OpenCV 2.3.3 with Fink and it works well
should I embbed the library in the mach-o ? if so, I don't how to...
"embed" in this context does not mean "static linking" (as in: embedding into the binary file), but rather shipping "side-by-side" (as in: embedding into the zip-file/install-directory).
hans' script will simply fix the search-paths in the .pd_darwin file (so it first searches for libopencv_core.2.3.dylib in '.' (besides the pd_darwin), rather than in /sw/lib or /usr/local/lib)
gmsdr IOhannes
thanks for the clarification :-)
-- do it yourself http://antoine.villeret.free.fr
2013/2/8 IOhannes zmölnig zmoelnig@iem.at
On 02/08/2013 01:07 AM, Antoine Villeret wrote:
hi,
thanks for the feedback,
I thought it was dynamically linked I tested it on a Mac OS 10.6.6 32bit machine where I installed OpenCV 2.3.3 with Fink and it works well
should I embbed the library in the mach-o ? if so, I don't how to...
"embed" in this context does not mean "static linking" (as in: embedding into the binary file), but rather shipping "side-by-side" (as in: embedding into the zip-file/install-directory).
hans' script will simply fix the search-paths in the .pd_darwin file (so it first searches for libopencv_core.2.3.dylib in '.' (besides the pd_darwin), rather than in /sw/lib or /usr/local/lib)
gmsdr IOhannes
______________________________**_________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/**listinfo/gem-devhttp://lists.puredata.info/listinfo/gem-dev
On 12/27/2012 16:03, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include
how about using pkg-config? Gem installs a "Gem.pc" file, so you should do something like CFLAGS_linux = `pkg-config --cflags opencv Gem`
fgmsdar IOhannes
cool ! shame on me, I didn't know this feature of Gem Makefile is updated in the SVN according to that
+ a -- do it yourself http://antoine.villeret.free.fr
2012/12/27 IOhannes m zmölnig zmoelnig@iem.at:
On 12/27/2012 16:03, Antoine Villeret wrote:
the default make install command from git repo install gem into /usr/local/include
how about using pkg-config? Gem installs a "Gem.pc" file, so you should do something like CFLAGS_linux = `pkg-config --cflags opencv Gem`
fgmsdar IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Antoine Villeret -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
IOhannes zmölnig
-
me.grimm