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 <h...@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 <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
