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.ville...@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 <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.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 <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
>
--
____________________
m.e.grimm | m.f.a | ed.m.
megr...@gmail.com
_________________________________
_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
