[GEM-dev] [PD-dev] pix_opencv

Thu Jan 31 17:49:17 CET 2013

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 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 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 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 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 at.or.at>:
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 13, 2012, at 12:21 PM, Antoine Villeret wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> 2012/12/13 Hans-Christoph Steiner <hans at 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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20130131/175c8be0/attachment-0001.htm>