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 >>> >>> >