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 <h...@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 <h...@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 <h...@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 <h...@at.or.at>: >>>>>>> >>>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote: >>>>>>> >>>>>>>> 2012/12/13 Hans-Christoph Steiner <h...@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_opencv/Makefile?r1=12563&r2=12571 >>>>>>>> >>>>>>>> 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
