From noreply at sourceforge.net  Sun Dec  2 15:22:32 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 02 Dec 2012 06:22:32 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3517368 ] gem 0.93 does not play .mpg files
	on Mac OS X
Message-ID: <mailman.246.1354458194.2527.gem-dev@iem.at>

Bugs item #3517368, was opened at 2012-04-12 19:30
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3517368&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: gem 0.93 does not play .mpg files on Mac OS X

Initial Comment:
Pd-extended 0.43.1, 2012-04-02 32-bit on a MacBook Pro 3,1 running Mac OS X 10.6.8/Intel.

opening Gem -> examples -> 04.pix -> 05.film, then loading alea.mpg, it tells me the video is "1 frames (320x240) at 1.000000 fps" and procedes to make a fractal-like animation.  Full Pd window log and screenshot attached

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-02 06:22

Message:
I was suggested this web site by my cousin. I am not sure whether this post
is written by him as nobody else know such detailed about my trouble.
You??re wonderful! Thanks!
 <a
href="http://workitmom.com/blogs/members/yak38twig/106795/asdfStylize%20Your%20own%20apple%20iphone%204g%20within%20a%20Elegant%20Method"
title="Stylize">Stylize</a>

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-09-23 11:00

Message:
Just built master and it still doesn't work, did it work for you?  But
things have changed: now it outputs -1 for the frame count for alea.mpg. 
Sending [auto 1( doesn't do anything at first, but after a couple seconds,
it plays a few frames, then stops again. 

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-09-23 10:12

Message:
I just tested this again to be sure:

- Pd-extended 0.42.5 i386 32-bit on Mac OS X 10.6.8/Intel:  When I load
alea.mpg, it outputs 0 from the total frames outlet but sending [auto 1( it
plays fine.

- Pd-extended 0.43.1-20120419 i386 32-bit on Mac OS X 10.6.8/Intel:  When I
load alea.mpg, it outputs 1 from the total frames outlet but sending [auto
1( does not play it.

Trying to build Gem from master now, I'll report back on that.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-05-02 06:33

Message:
Just did a little more testing.  alea.mpg and 64849285.mp4 both play fine
in Quicktime and in Pd-extended 0.42.5.  It is only Pd-extended 0.43.1 with
Gem 0.93 that has this issue

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-23 11:31

Message:
I just tested this using
Pd-0.43.1-extended-20120423-ubuntu-oneiric-i386.deb on Ubuntu Oneiric/i386
on my MacBook Pro 3,1 with a nVidia Corporation G84 [GeForce 8600M GT] . 
It seems to work fine with alea.mpg, /64849285.mp4, and others all work
fine.  Seems like its an OSX issue.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-22 06:34

Message:
yes, both play fine.  alea.mpg is the same old video that has been included
in Gem forever

----------------------------------------------------------------------

Comment By: IOhannes m zm??lnig (zmoelnig)
Date: 2012-04-22 02:46

Message:
can you play these movies with QuickTime?

----------------------------------------------------------------------

Comment By: jack  (jackovic)
Date: 2012-04-17 15:18

Message:
The video works fine on my config. Last Gem from git, Pd 0.43.2test1,
ubuntu 11.10. Here i get :
[pix_film]: loaded file: /home/jack/Vid??os/filmsPourTests/64849285.mp4
with 359 frames (640x480) at 30.000000 fps
So the problem seems to be related to MasOSX only.
++

Jack



----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-17 10:43

Message:
I am also seeing the same behavior using a mp4 from the internet:
[pix_film]: loaded file: /Users/hans/64849285.mp4 with 1 frames (640x480)
at 1.000000 fps

This is the video, you can download the .mp4 from the download section of
the page:
http://vimeo.com/28911883

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3517368&group_id=64325


From noreply at sourceforge.net  Mon Dec  3 09:53:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 00:53:15 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3517368 ] gem 0.93 does not play .mpg files
	on Mac OS X
Message-ID: <mailman.265.1354524841.2527.gem-dev@iem.at>

Bugs item #3517368, was opened at 2012-04-12 19:30
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3517368&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: gem 0.93 does not play .mpg files on Mac OS X

Initial Comment:
Pd-extended 0.43.1, 2012-04-02 32-bit on a MacBook Pro 3,1 running Mac OS X 10.6.8/Intel.

opening Gem -> examples -> 04.pix -> 05.film, then loading alea.mpg, it tells me the video is "1 frames (320x240) at 1.000000 fps" and procedes to make a fractal-like animation.  Full Pd window log and screenshot attached

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-03 00:53

Message:
This article is quite assuredly written for those of us that like to really
think. The particular points you make appear intelligent and well-defined.
Your perception of this topic is much like mine. Thank you.
 <a href="http://eyeuser.com/blogs/viewstory/329188" title="a Perfect">a
Perfect</a>

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-09-23 11:00

Message:
Just built master and it still doesn't work, did it work for you?  But
things have changed: now it outputs -1 for the frame count for alea.mpg. 
Sending [auto 1( doesn't do anything at first, but after a couple seconds,
it plays a few frames, then stops again. 

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-09-23 10:12

Message:
I just tested this again to be sure:

- Pd-extended 0.42.5 i386 32-bit on Mac OS X 10.6.8/Intel:  When I load
alea.mpg, it outputs 0 from the total frames outlet but sending [auto 1( it
plays fine.

- Pd-extended 0.43.1-20120419 i386 32-bit on Mac OS X 10.6.8/Intel:  When I
load alea.mpg, it outputs 1 from the total frames outlet but sending [auto
1( does not play it.

Trying to build Gem from master now, I'll report back on that.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-05-02 06:33

Message:
Just did a little more testing.  alea.mpg and 64849285.mp4 both play fine
in Quicktime and in Pd-extended 0.42.5.  It is only Pd-extended 0.43.1 with
Gem 0.93 that has this issue

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-23 11:31

Message:
I just tested this using
Pd-0.43.1-extended-20120423-ubuntu-oneiric-i386.deb on Ubuntu Oneiric/i386
on my MacBook Pro 3,1 with a nVidia Corporation G84 [GeForce 8600M GT] . 
It seems to work fine with alea.mpg, /64849285.mp4, and others all work
fine.  Seems like its an OSX issue.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-22 06:34

Message:
yes, both play fine.  alea.mpg is the same old video that has been included
in Gem forever

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2012-04-22 02:46

Message:
can you play these movies with QuickTime?

----------------------------------------------------------------------

Comment By: jack  (jackovic)
Date: 2012-04-17 15:18

Message:
The video works fine on my config. Last Gem from git, Pd 0.43.2test1,
ubuntu 11.10. Here i get :
[pix_film]: loaded file: /home/jack/Vid?os/filmsPourTests/64849285.mp4
with 359 frames (640x480) at 30.000000 fps
So the problem seems to be related to MasOSX only.
++

Jack



----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-17 10:43

Message:
I am also seeing the same behavior using a mp4 from the internet:
[pix_film]: loaded file: /Users/hans/64849285.mp4 with 1 frames (640x480)
at 1.000000 fps

This is the video, you can download the .mp4 from the download section of
the page:
http://vimeo.com/28911883

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3517368&group_id=64325


From noreply at sourceforge.net  Mon Dec  3 10:52:15 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 01:52:15 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3512435 ] abstractions/gemwin.pd couldn't
	create
Message-ID: <mailman.266.1354528375.2527.gem-dev@iem.at>

Bugs item #3512435, was opened at 2012-03-28 08:40
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3512435&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build-system
Group: osx
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: megrimm (megrimm)
Assigned to: Nobody/Anonymous (nobody)
Summary: abstractions/gemwin.pd couldn't create

Initial Comment:
User patches (non-example patches) give error when creating gem abstractions (example: abstractions/gemwin.pd) even when [import Gem], etc is used.

For example, "gemwin ... couldn't create", "gemorb ... couldn't create"

do gem abstractions just need alias's made in parent directory ? although I am assuming there with be conflicts between abstractions and externals/gem-internals such as "gemhead"?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-03 01:52

Message:
Wonderful blog you have here but I was curious if you knew of any
discussion boards that cover the same topics talked about here? I'd really
like to be a part of community where I can get advice from other
knowledgeable people that share the same interest. If you have any
suggestions, please let me know. Thanks a lot!
north face osito http://workathometopics.com/?p=435356

----------------------------------------------------------------------

Comment By: megrimm (megrimm)
Date: 2012-03-29 06:25

Message:
OK. You are correct in that. Although I think the confusion was in the fact
that a "make install" (at least on OSX) installs gem to
"/usr/local/lib/pd/extra/" rather than "~/Library/Pd/Gem".....

should it or should it not i do not know...



----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2012-03-29 06:11

Message:
no, you should not need an alias in the parent path.

Gem expects the abstractions to live in the same directory as the
Gem-binary (Gem.pd_darwin in your case), and (if properly compiled and
installed [*]), will add this directory to Pd's search paths.

if things go wrong, you might want to run pd with "-verbose" flag, to see
whether it spits something out regarding it's search path.

what [import Gem] does in don't know.



[*] properly compiled means, that "s_stuff.h" was found during compilation;
properly installed means, that _all_ Gem-abstractions (including the
special Gem-meta.pd)

----------------------------------------------------------------------

Comment By: megrimm (megrimm)
Date: 2012-03-28 08:41

Message:
thats
pd-extended-0.43.1_64bit
gem recent git pull

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3512435&group_id=64325


From noreply at sourceforge.net  Mon Dec  3 10:52:26 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 01:52:26 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3541589 ] pix_record codeclist
Message-ID: <mailman.267.1354528384.2527.gem-dev@iem.at>

Bugs item #3541589, was opened at 2012-07-09 05:59
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3541589&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: linux
Status: Pending
Resolution: Works For Me
Priority: 1
Private: No
Submitted By: kubriel (kubriel)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_record codeclist

Initial Comment:
there is no output to console in linux when inserting [codeclist( co pix_record in gem from git 3.7.2012.
i cant set any other codec as mjpa seen in example, because i dont know its name.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-03 01:52

Message:
Do you have a spam issue on this blog; I also am a blogger, and I was
wanting to know your situation; many of us have developed some nice
practices and we are looking to exchange techniques with others, be sure to
shoot me an email if interested.
cheap north face http://microadvert.net/node/190074

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2012-07-23 09:56

Message:
actually printout does work, but you have to manually raise the verbosity
of Pd to level 2, by adding the following flags when starting Pd: "-verbose
-verbose" 

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2012-07-12 07:02

Message:
the codeclist is sent to the last outlet of [pix_record], just attach a
[print] to it. this allows the codecname  not only to be displayed, but
also to be used programmatically.

in theory, the codeclist should also be posted at a higher verbose level
(so you won't get annoyed by all those codecs by default), but it seems
that this is currently not working as expected.
i'll try to fix that later.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3541589&group_id=64325


From noreply at sourceforge.net  Mon Dec  3 10:52:33 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 01:52:33 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3513016 ] imageMAGICK plugin Inverted
	Colors on file read
Message-ID: <mailman.268.1354528389.2527.gem-dev@iem.at>

Bugs item #3513016, was opened at 2012-03-29 16:55
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3513016&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: osx
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: megrimm (megrimm)
Assigned to: Nobody/Anonymous (nobody)
Summary: imageMAGICK plugin Inverted Colors on file read

Initial Comment:
pd-extended 64bit osx 10.7.3

When opening a file the Red channel and the Green channel were inverted.

FIX: 

Line 54: GL_RGB
Line 60: "BGR"

...that fix took me half the day to figure out. anyway, i know i should be submitting a patch but im not too illiterate yet on the git systems and was failing quite miserably in my attempts to create a suitable patch....

m

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-03 01:52

Message:
Hello, I think your website might be having browser compatibility issues.
When I look at your blog site in Safari, it looks fine but when opening in
Internet Explorer, it has some overlapping. I just wanted to give you a
quick heads up! Other then that, wonderful blog!
cheap north face jackets http://cheapnorthfacewintercoats.jimdo.com/

----------------------------------------------------------------------

Comment By: megrimm (megrimm)
Date: 2012-05-02 10:54

Message:
yeah I am not sure what to say. I realize this is probably a larger
problem. I just added the alpha channel and compiled only to get the same
discoloration. the solution i presented seemed to be the only one that get
adequate results.

for the 64 bit builds ive been looking at starting an native cocoa plugin
for images but i would need some direction. I am not so sure how to utilize
Objective-C code (in cocoa we would be using NSImage) in a C++ application.
This could just be the easy better solution?

let me know what you need for me to work all this out....

m

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2012-05-02 06:15

Message:
the problem with that fix is, that we are potentially losing the alpha
channel of the image, which is not so good.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3513016&group_id=64325


From noreply at sourceforge.net  Mon Dec  3 10:52:34 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 03 Dec 2012 01:52:34 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3517368 ] gem 0.93 does not play .mpg files
	on Mac OS X
Message-ID: <mailman.269.1354528392.2527.gem-dev@iem.at>

Bugs item #3517368, was opened at 2012-04-12 19:30
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3517368&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: gem 0.93 does not play .mpg files on Mac OS X

Initial Comment:
Pd-extended 0.43.1, 2012-04-02 32-bit on a MacBook Pro 3,1 running Mac OS X 10.6.8/Intel.

opening Gem -> examples -> 04.pix -> 05.film, then loading alea.mpg, it tells me the video is "1 frames (320x240) at 1.000000 fps" and procedes to make a fractal-like animation.  Full Pd window log and screenshot attached

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-03 01:52

Message:
With havin so much content do you ever run into any problems of plagorism
or copyright infringement? My website has a lot of unique content I've
either written myself or outsourced but it appears a lot of it is popping
it up all over the web without my agreement. Do you know any methods to
help stop content from being ripped off? I'd genuinely appreciate it.
[url=http://outlets3.urbanblog.dk/2012/12/01/discount-north-face-vivid/]cheap
north face jackets[/url]

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-03 00:53

Message:
This article is quite assuredly written for those of us that like to really
think. The particular points you make appear intelligent and well-defined.
Your perception of this topic is much like mine. Thank you.
 <a href="http://eyeuser.com/blogs/viewstory/329188" title="a Perfect">a
Perfect</a>

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-09-23 11:00

Message:
Just built master and it still doesn't work, did it work for you?  But
things have changed: now it outputs -1 for the frame count for alea.mpg. 
Sending [auto 1( doesn't do anything at first, but after a couple seconds,
it plays a few frames, then stops again. 

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-09-23 10:12

Message:
I just tested this again to be sure:

- Pd-extended 0.42.5 i386 32-bit on Mac OS X 10.6.8/Intel:  When I load
alea.mpg, it outputs 0 from the total frames outlet but sending [auto 1( it
plays fine.

- Pd-extended 0.43.1-20120419 i386 32-bit on Mac OS X 10.6.8/Intel:  When I
load alea.mpg, it outputs 1 from the total frames outlet but sending [auto
1( does not play it.

Trying to build Gem from master now, I'll report back on that.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-05-02 06:33

Message:
Just did a little more testing.  alea.mpg and 64849285.mp4 both play fine
in Quicktime and in Pd-extended 0.42.5.  It is only Pd-extended 0.43.1 with
Gem 0.93 that has this issue

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-23 11:31

Message:
I just tested this using
Pd-0.43.1-extended-20120423-ubuntu-oneiric-i386.deb on Ubuntu Oneiric/i386
on my MacBook Pro 3,1 with a nVidia Corporation G84 [GeForce 8600M GT] . 
It seems to work fine with alea.mpg, /64849285.mp4, and others all work
fine.  Seems like its an OSX issue.

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-22 06:34

Message:
yes, both play fine.  alea.mpg is the same old video that has been included
in Gem forever

----------------------------------------------------------------------

Comment By: IOhannes m zm?lnig (zmoelnig)
Date: 2012-04-22 02:46

Message:
can you play these movies with QuickTime?

----------------------------------------------------------------------

Comment By: jack  (jackovic)
Date: 2012-04-17 15:18

Message:
The video works fine on my config. Last Gem from git, Pd 0.43.2test1,
ubuntu 11.10. Here i get :
[pix_film]: loaded file: /home/jack/Vid?os/filmsPourTests/64849285.mp4
with 359 frames (640x480) at 30.000000 fps
So the problem seems to be related to MasOSX only.
++

Jack



----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-04-17 10:43

Message:
I am also seeing the same behavior using a mp4 from the internet:
[pix_film]: loaded file: /Users/hans/64849285.mp4 with 1 frames (640x480)
at 1.000000 fps

This is the video, you can download the .mp4 from the download section of
the page:
http://vimeo.com/28911883

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3517368&group_id=64325


From tofuckof at inbox.ru  Thu Dec  6 14:35:07 2012
From: tofuckof at inbox.ru (=?UTF-8?B?0KTRi9Cy0LDQv9GAINCe0LvQtNC20Y3QstC40Yc=?=)
Date: Thu, 06 Dec 2012 17:35:07 +0400
Subject: [GEM-dev] =?utf-8?q?pics_with_transparency?=
Message-ID: <1354800907.793906888@f371.mail.ru>

Hello !

Can anyone help ?

How can I render a picture with transparent layer ? 

Or maybe other way to remder and be able to scale and translate picture with no background ?

Right now I have to work with 3-D models of the pictures with 0-thick .. but it renders not enough quality as just a picture. 

But i don;t need backgorund in them and need holes sometimes. 

Thanks !!?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20121206/d0093e87/attachment.htm>

From ch at chnry.net  Thu Dec  6 15:22:07 2012
From: ch at chnry.net (Cyrille Henry)
Date: Thu, 06 Dec 2012 15:22:07 +0100
Subject: [GEM-dev] pics with transparency
In-Reply-To: <1354800907.793906888@f371.mail.ru>
References: <1354800907.793906888@f371.mail.ru>
Message-ID: <50C0AA0F.8090108@chnry.net>



Le 06/12/2012 14:35, ?????? ???????? a ?crit :
> Hello !
>
> Can anyone help ?
>
> How can I render a picture with transparent layer ?
use a picture with a transparency layer, and insert a [alpha] object after gemhead so that transparency is computed.
cheers
c

>
> Or maybe other way to remder and be able to scale and translate picture with no background ?
>
> Right now I have to work with 3-D models of the pictures with 0-thick .. but it renders not enough quality as just a picture.
>
> But i don;t need backgorund in them and need holes sometimes.
>
> Thanks !!
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>


From ch at chnry.net  Thu Dec  6 16:36:41 2012
From: ch at chnry.net (Cyrille Henry)
Date: Thu, 06 Dec 2012 16:36:41 +0100
Subject: [GEM-dev] pics with transparency
In-Reply-To: <1354807990.502213977@f272.mail.ru>
References: <1354807990.502213977@f272.mail.ru>
Message-ID: <50C0BB89.4050607@chnry.net>


tif should work on any platform.


Le 06/12/2012 16:33, ?????? ???????? a ?crit :
> Thanks, and what format the picture should be ?
>
> So the [pix_image] doesn'read PNG or PSD ..
>
>
>
>
> ???????, 6 ??????? 2012, 15:22 ?? Cyrille Henry <ch at chnry.net>:
>
>
>
>     Le 06/12/2012 14:35, ?????? ???????? a ?crit :
>      > Hello !
>      >
>      > Can anyone help ?
>      >
>      > How can I render a picture with transparent layer ?
>     use a picture with a transparency layer, and insert a [alpha] object after gemhead so that transparency is computed.
>     cheers
>     c
>
>      >
>      > Or maybe other way to remder and be able to scale and translate picture with no background ?
>      >
>      > Right now I have to work with 3-D models of the pictures with 0-thick .. but it renders not enough quality as just a picture.
>      >
>      > But i don;t need backgorund in them and need holes sometimes.
>      >
>      > Thanks !!
>      >
>      >
>      > _______________________________________________
>      > GEM-dev mailing list
>      > GEM-dev at iem.at <sentmsg?compose&To=GEM%2ddev at iem.at>
>      > http://lists.puredata.info/listinfo/gem-dev
>      >
>
>


From tofuckof at inbox.ru  Thu Dec  6 16:33:10 2012
From: tofuckof at inbox.ru (=?UTF-8?B?0KTRi9Cy0LDQv9GAINCe0LvQtNC20Y3QstC40Yc=?=)
Date: Thu, 06 Dec 2012 19:33:10 +0400
Subject: [GEM-dev] =?utf-8?q?pics_with_transparency?=
Message-ID: <1354807990.502213977@f272.mail.ru>

Thanks, and what format the picture should be ?

So the [pix_image] doesn'read PNG or PSD ..?




???????,  6 ??????? 2012, 15:22  ?? Cyrille Henry <ch at chnry.net>:
>	
>
>
	
	
>
		
		
			
>
>

>
Le 06/12/2012 14:35, ?????? ???????? a ?crit :
>
> Hello !
>
>
>
> Can anyone help ?
>
>
>
> How can I render a picture with transparent layer ?
>
use a picture with a transparency layer, and insert a [alpha] object after gemhead so that transparency is computed.
>
cheers
>
c
>

>
>
>
> Or maybe other way to remder and be able to scale and translate picture with no background ?
>
>
>
> Right now I have to work with 3-D models of the pictures with 0-thick .. but it renders not enough quality as just a picture.
>
>
>
> But i don;t need backgorund in them and need holes sometimes.
>
>
>
> Thanks !!
>
>
>
>
>
> _______________________________________________
>
> GEM-dev mailing list
>
> GEM-dev at iem.at
>
> http://lists.puredata.info/listinfo/gem-dev
>
>
>
>			
		
		
	

	
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20121206/90a08c70/attachment.htm>

From tofuckof at inbox.ru  Thu Dec  6 16:47:44 2012
From: tofuckof at inbox.ru (=?UTF-8?B?0KTRi9Cy0LDQv9GAINCe0LvQtNC20Y3QstC40Yc=?=)
Date: Thu, 06 Dec 2012 19:47:44 +0400
Subject: [GEM-dev] =?utf-8?q?pics_with_transparency?=
Message-ID: <1354808864.873157315@f272.mail.ru>

but i mean the format of file ? ?

i'm not profi in it.. ? should i use TIFF file or wht the format with transparent layer it could be ?


???????,  6 ??????? 2012, 16:36  ?? Cyrille Henry <ch at chnry.net>:
>	
>
>
	
	
>
		
		
			
>
>
tif should work on any platform.
>

>

>
Le 06/12/2012 16:33, ?????? ???????? a ?crit :
>
> Thanks, and what format the picture should be ?
>
>
>
> So the [pix_image] doesn'read PNG or PSD ..
>
>
>
>
>
>
>
>
>
> ???????, 6 ??????? 2012, 15:22 ?? Cyrille Henry <ch at chnry.net>:
>
>
>
>
>
>
>
>     Le 06/12/2012 14:35, ?????? ???????? a ?crit :
>
>      > Hello !
>
>      >
>
>      > Can anyone help ?
>
>      >
>
>      > How can I render a picture with transparent layer ?
>
>     use a picture with a transparency layer, and insert a [alpha] object after gemhead so that transparency is computed.
>
>     cheers
>
>     c
>
>
>
>      >
>
>      > Or maybe other way to remder and be able to scale and translate picture with no background ?
>
>      >
>
>      > Right now I have to work with 3-D models of the pictures with 0-thick .. but it renders not enough quality as just a picture.
>
>      >
>
>      > But i don;t need backgorund in them and need holes sometimes.
>
>      >
>
>      > Thanks !!
>
>      >
>
>      >
>
>      > _______________________________________________
>
>      > GEM-dev mailing list
>
>      > GEM-dev at iem.at <sentmsg?compose&To=GEM%2ddev at iem.at>
>
>      > http://lists.puredata.info/listinfo/gem-dev
>
>      >
>
>
>
>
>
>			
		
		
	

	
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20121206/03272295/attachment.htm>

From zmoelnig at iem.at  Thu Dec  6 18:25:09 2012
From: zmoelnig at iem.at (=?UTF-8?B?SU9oYW5uZXMgbSB6bcO2bG5pZw==?=)
Date: Thu, 06 Dec 2012 18:25:09 +0100
Subject: [GEM-dev] pics with transparency
In-Reply-To: <1354808864.873157315@f272.mail.ru>
References: <1354808864.873157315@f272.mail.ru>
Message-ID: <50C0D4F5.8080704@iem.at>

On 12/06/2012 16:47, ?????? ???????? wrote:
> but i mean the format of file ?
>
> i'm not profi in it.. should i use TIFF file or wht the format with
> transparent layer it could be ?

that's what cyrille wrote: "tif" or "TIFF" both mean "Tag Image File 
Format".
it's a image fileformat with transparency.


fgadmsr
IOhannes


From antoine.villeret at gmail.com  Fri Dec  7 01:50:49 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Fri, 7 Dec 2012 01:50:49 +0100
Subject: [GEM-dev] pix_set new features
Message-ID: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>

hi all,

i've added some new features to pix_set :
- roisize and roioffset which allow to set only a small part of the whole image
- fill which set all the pixels by sending only one value (no need to
make a huge list...)

the help patch have been updated
and i also make an example 04.pix/27.bitmap_font.pd

feedback are welcome
feel free to include it in Gem
i'm using it to display text and other simple graphics on a LED matrix

this is in my github repos on the branch "pix_set"
git://github.com/avilleret/Gem.git

++
a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


From ch at chnry.net  Fri Dec  7 11:16:31 2012
From: ch at chnry.net (Cyrille Henry)
Date: Fri, 07 Dec 2012 11:16:31 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
Message-ID: <50C1C1FF.4010805@chnry.net>

wow, cool,

thanks

Cyrille

Le 07/12/2012 01:50, Antoine Villeret a ?crit :
> hi all,
>
> i've added some new features to pix_set :
> - roisize and roioffset which allow to set only a small part of the whole image
> - fill which set all the pixels by sending only one value (no need to
> make a huge list...)
>
> the help patch have been updated
> and i also make an example 04.pix/27.bitmap_font.pd
>
> feedback are welcome
> feel free to include it in Gem
> i'm using it to display text and other simple graphics on a LED matrix
>
> this is in my github repos on the branch "pix_set"
> git://github.com/avilleret/Gem.git
>
> ++
> a
> --
> do it yourself
> http://antoine.villeret.free.fr
> http://drii.ensad.fr
> --
> Google lit ce mail...
> si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
> pour me contacter
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>


From zmoelnig at iem.at  Fri Dec  7 13:14:12 2012
From: zmoelnig at iem.at (=?ISO-8859-15?Q?IOhannes_m_zm=F6lnig?=)
Date: Fri, 07 Dec 2012 13:14:12 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
Message-ID: <50C1DD94.8010705@iem.at>

On 12/07/2012 01:50, Antoine Villeret wrote:
> hi all,
>
> i've added some new features to pix_set :
> - roisize and roioffset which allow to set only a small part of the whole image
> - fill which set all the pixels by sending only one value (no need to
> make a huge list...)
>
> the help patch have been updated
> and i also make an example 04.pix/27.bitmap_font.pd
>
> feedback are welcome
> feel free to include it in Gem

thanks for your patches.

eventually i would like to have generic ROI support for all pix_ objects 
(apart from some objects where it doesn't make sense).
this however, would require a "rewrite" (substantial adaption) of the 
processing core of all objects :-(


fgmasdr
IOhannes


From antoine.villeret at gmail.com  Fri Dec  7 13:39:22 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Fri, 7 Dec 2012 13:39:22 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C1DD94.8010705@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
Message-ID: <CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>

i think this is a good idea
i usually make changes to pix_object to fit the requirement of my
working projects
if i have the opportunity to do that for other objects (and i hope
this happens soon) i'll let you know

best

a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/7 IOhannes m zm?lnig <zmoelnig at iem.at>:
> On 12/07/2012 01:50, Antoine Villeret wrote:
>>
>> hi all,
>>
>> i've added some new features to pix_set :
>> - roisize and roioffset which allow to set only a small part of the whole
>> image
>> - fill which set all the pixels by sending only one value (no need to
>> make a huge list...)
>>
>> the help patch have been updated
>> and i also make an example 04.pix/27.bitmap_font.pd
>>
>> feedback are welcome
>> feel free to include it in Gem
>
>
> thanks for your patches.
>
> eventually i would like to have generic ROI support for all pix_ objects
> (apart from some objects where it doesn't make sense).
> this however, would require a "rewrite" (substantial adaption) of the
> processing core of all objects :-(
>
>
> fgmasdr
> IOhannes
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From zmoelnig at iem.at  Tue Dec 11 09:55:36 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 11 Dec 2012 09:55:36 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
Message-ID: <50C6F508.5080302@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-12-07 13:39, Antoine Villeret wrote:
> i think this is a good idea i usually make changes to pix_object to
> fit the requirement of my working projects if i have the
> opportunity to do that for other objects (and i hope this happens
> soon) i'll let you know


so my plan is actually something like this:
- - add a new property "ROI" to the GemState.
- - add a new object [pix_roi] that allows you to set the roi in a
normalized form (0..1 rather than 0..<width>); this object will simply
set the "ROI" property.
- - have the pix_objects use these roi-property.

in order for the latter to work more consistently, it would be nice
(in a 2nd step?), to change the architecture of the pix_objects slightly:

- - add new virtual methods called like
  processLineRGBA(void*data, unsigned int width, imageStruct*img);

for line-wise processing (with context).

GemPixObject would then take care of calling processLine correctly for
the given ROI.


if done correctly, we could also utilize this to allow parallel
processing of pixes as well (see [1].

fgmasdr
IOhannes

[1]
http://hirntier.blogspot.co.at/2009/02/parallelizing-video-routines.html



> 
> best
> 
> a -- do it yourself http://antoine.villeret.free.fr 
> http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela,
> utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
> 
> 
> 2012/12/7 IOhannes m zm?lnig <zmoelnig at iem.at>:
>> On 12/07/2012 01:50, Antoine Villeret wrote:
>>> 
>>> hi all,
>>> 
>>> i've added some new features to pix_set : - roisize and
>>> roioffset which allow to set only a small part of the whole 
>>> image - fill which set all the pixels by sending only one value
>>> (no need to make a huge list...)
>>> 
>>> the help patch have been updated and i also make an example
>>> 04.pix/27.bitmap_font.pd
>>> 
>>> feedback are welcome feel free to include it in Gem
>> 
>> 
>> thanks for your patches.
>> 
>> eventually i would like to have generic ROI support for all pix_
>> objects (apart from some objects where it doesn't make sense). 
>> this however, would require a "rewrite" (substantial adaption) of
>> the processing core of all objects :-(
>> 
>> 
>> fgmasdr IOhannes
>> 
>> 
>> _______________________________________________ GEM-dev mailing
>> list GEM-dev at iem.at http://lists.puredata.info/listinfo/gem-dev
> 
> _______________________________________________ GEM-dev mailing
> list GEM-dev at iem.at http://lists.puredata.info/listinfo/gem-dev
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDG9QQACgkQkX2Xpv6ydvTC8QCfUE8isxKGWz7EKPS4Vz7aNk6w
bk8AnjRUwJdQw5r9opjCkDAmyFl5JUup
=lJyp
-----END PGP SIGNATURE-----


From antoine.villeret at gmail.com  Tue Dec 11 14:16:50 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Tue, 11 Dec 2012 14:16:50 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C6F508.5080302@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
Message-ID: <CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>

it sounds great,

how can I help ?
who starts ?

+
a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/11 IOhannes m zmoelnig <zmoelnig at iem.at>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2012-12-07 13:39, Antoine Villeret wrote:
>> i think this is a good idea i usually make changes to pix_object to
>> fit the requirement of my working projects if i have the
>> opportunity to do that for other objects (and i hope this happens
>> soon) i'll let you know
>
>
> so my plan is actually something like this:
> - - add a new property "ROI" to the GemState.
> - - add a new object [pix_roi] that allows you to set the roi in a
> normalized form (0..1 rather than 0..<width>); this object will simply
> set the "ROI" property.
> - - have the pix_objects use these roi-property.
>
> in order for the latter to work more consistently, it would be nice
> (in a 2nd step?), to change the architecture of the pix_objects slightly:
>
> - - add new virtual methods called like
>   processLineRGBA(void*data, unsigned int width, imageStruct*img);
>
> for line-wise processing (with context).
>
> GemPixObject would then take care of calling processLine correctly for
> the given ROI.
>
>
> if done correctly, we could also utilize this to allow parallel
> processing of pixes as well (see [1].
>
> fgmasdr
> IOhannes
>
> [1]
> http://hirntier.blogspot.co.at/2009/02/parallelizing-video-routines.html
>
>
>
>>
>> best
>>
>> a -- do it yourself http://antoine.villeret.free.fr
>> http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela,
>> utilisez l'adresse antoine.villeret [at] free.fr pour me contacter
>>
>>
>> 2012/12/7 IOhannes m zm?lnig <zmoelnig at iem.at>:
>>> On 12/07/2012 01:50, Antoine Villeret wrote:
>>>>
>>>> hi all,
>>>>
>>>> i've added some new features to pix_set : - roisize and
>>>> roioffset which allow to set only a small part of the whole
>>>> image - fill which set all the pixels by sending only one value
>>>> (no need to make a huge list...)
>>>>
>>>> the help patch have been updated and i also make an example
>>>> 04.pix/27.bitmap_font.pd
>>>>
>>>> feedback are welcome feel free to include it in Gem
>>>
>>>
>>> thanks for your patches.
>>>
>>> eventually i would like to have generic ROI support for all pix_
>>> objects (apart from some objects where it doesn't make sense).
>>> this however, would require a "rewrite" (substantial adaption) of
>>> the processing core of all objects :-(
>>>
>>>
>>> fgmasdr IOhannes
>>>
>>>
>>> _______________________________________________ GEM-dev mailing
>>> list GEM-dev at iem.at http://lists.puredata.info/listinfo/gem-dev
>>
>> _______________________________________________ GEM-dev mailing
>> list GEM-dev at iem.at http://lists.puredata.info/listinfo/gem-dev
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlDG9QQACgkQkX2Xpv6ydvTC8QCfUE8isxKGWz7EKPS4Vz7aNk6w
> bk8AnjRUwJdQw5r9opjCkDAmyFl5JUup
> =lJyp
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From zmoelnig at iem.at  Tue Dec 11 18:02:05 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 11 Dec 2012 18:02:05 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
Message-ID: <50C7670D.8040107@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-12-11 14:16, Antoine Villeret wrote:
> it sounds great,
> 
> how can I help ? who starts ?

i started to implement [pix_roi] and adapted [pix_set] accordingly.

[pix_set] now also tries to write on an incoming image (rather than
always using it's own image). hopefully this won't break anything.


check whether it does what it should.

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDHZwoACgkQkX2Xpv6ydvRKjwCeL1TkkDCUBDclPGijlqmOEwbw
N2AAoNZhdnV+BdN6Jbn4r55n4w2eBLAO
=NL2h
-----END PGP SIGNATURE-----


From antoine.villeret at gmail.com  Tue Dec 11 18:48:55 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Tue, 11 Dec 2012 18:48:55 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C7670D.8040107@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
Message-ID: <CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>

is does

thanks

while i understood the need of normalized coordinates for texture in
OpenGL, i dislike it in pix_objets, because we deal with array of pix
and i think it's more human readable to use pixel coordinate in this
case
this also add some conversion both in the code and in the patch
but this is only my point of view

i started a pix_roi-help.pd and updated pix_set-help.pd (remove my roi
messages) (in my repos, on master branch
git://github.com/avilleret/Gem.git)

+
a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/11 IOhannes m zmoelnig <zmoelnig at iem.at>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2012-12-11 14:16, Antoine Villeret wrote:
>> it sounds great,
>>
>> how can I help ? who starts ?
>
> i started to implement [pix_roi] and adapted [pix_set] accordingly.
>
> [pix_set] now also tries to write on an incoming image (rather than
> always using it's own image). hopefully this won't break anything.
>
>
> check whether it does what it should.
>
> fgmasdr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlDHZwoACgkQkX2Xpv6ydvRKjwCeL1TkkDCUBDclPGijlqmOEwbw
> N2AAoNZhdnV+BdN6Jbn4r55n4w2eBLAO
> =NL2h
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From zmoelnig at iem.at  Tue Dec 11 19:00:22 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 11 Dec 2012 19:00:22 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
Message-ID: <50C774B6.4040701@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-12-11 18:48, Antoine Villeret wrote:
> is does
> 
> thanks
> 
> while i understood the need of normalized coordinates for texture
> in OpenGL, i dislike it in pix_objets, because we deal with array
> of pix and i think it's more human readable to use pixel coordinate
> in this case this also add some conversion both in the code and in
> the patch but this is only my point of view

i understand that (esp. in the context of pix_set), but i want ROI to
also work with simpler effects where you might want to specify an
area, where the effect is applied, without having to care about the
pix dimensions.
also Gem uses normalized values whenever possible.

> 
> i started a pix_roi-help.pd and updated pix_set-help.pd (remove my
> roi messages) (in my repos, on master branch 
> git://github.com/avilleret/Gem.git)
> 

cool

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDHdLQACgkQkX2Xpv6ydvT8qgCcDDsEjlQCUxCZh29v8GSNDKtr
brEAoKzyq02dP5/0R2MQmJHIpmaA/dPi
=qemJ
-----END PGP SIGNATURE-----


From zmoelnig at iem.at  Tue Dec 11 19:08:27 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 11 Dec 2012 19:08:27 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
Message-ID: <50C7769B.9060800@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-12-11 18:48, Antoine Villeret wrote:
> i started a pix_roi-help.pd and updated pix_set-help.pd (remove my
> roi messages) (in my repos, on master branch 
> git://github.com/avilleret/Gem.git)
> 

thanks applied. pushed.

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDHdpsACgkQkX2Xpv6ydvTJOgCgody/aSro0B/y25s6xvvejq6R
zboAniV+SV821x02Ez92sSgv5FFJ1Q6d
=4vJ6
-----END PGP SIGNATURE-----


From zmoelnig at iem.at  Tue Dec 11 19:16:16 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 11 Dec 2012 19:16:16 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C774B6.4040701@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
	<50C774B6.4040701@iem.at>
Message-ID: <50C77870.6020003@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-12-11 19:00, IOhannes m zmoelnig wrote:
> On 2012-12-11 18:48, Antoine Villeret wrote:
>> is does
> 
>> thanks
> 
>> while i understood the need of normalized coordinates for
>> texture in OpenGL, i dislike it in pix_objets, because we deal
>> with array of pix and i think it's more human readable to use
>> pixel coordinate in this case this also add some conversion both
>> in the code and in the patch but this is only my point of view
> 
> i understand that (esp. in the context of pix_set), but i want ROI
> to also work with simpler effects where you might want to specify
> an area, where the effect is applied, without having to care about
> the pix dimensions. also Gem uses normalized values whenever
> possible.
> 

however, i'm not so much opposed to add a special message to specify
the ROI in absolute values and [pix_roi] would then normalize the
values internally.

fgmadr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDHeHAACgkQkX2Xpv6ydvTIGQCeO2tuvkrwvMWD85eYk7wV17CE
o6AAoJjTHpoqTjp+UDuiK95zQHiWDbIm
=8jSq
-----END PGP SIGNATURE-----


From antoine.villeret at gmail.com  Tue Dec 11 19:24:45 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Tue, 11 Dec 2012 19:24:45 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C77870.6020003@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
	<50C774B6.4040701@iem.at> <50C77870.6020003@iem.at>
Message-ID: <CAGn5wNcjnZ=+jgNtQ=1C2hmNWzqTkBJ_kJXuCxP9po8ubWqBfQ@mail.gmail.com>

and what about the opposite ?
stay in discrete coordinate in the code and add a normalized message ?
in that way the conversion is done only once (when the ROI is set in
normalized coord) and not each time we set the data (for pix_set)
maybe i'm going wrong...

+
a


--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/11 IOhannes m zmoelnig <zmoelnig at iem.at>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2012-12-11 19:00, IOhannes m zmoelnig wrote:
>> On 2012-12-11 18:48, Antoine Villeret wrote:
>>> is does
>>
>>> thanks
>>
>>> while i understood the need of normalized coordinates for
>>> texture in OpenGL, i dislike it in pix_objets, because we deal
>>> with array of pix and i think it's more human readable to use
>>> pixel coordinate in this case this also add some conversion both
>>> in the code and in the patch but this is only my point of view
>>
>> i understand that (esp. in the context of pix_set), but i want ROI
>> to also work with simpler effects where you might want to specify
>> an area, where the effect is applied, without having to care about
>> the pix dimensions. also Gem uses normalized values whenever
>> possible.
>>
>
> however, i'm not so much opposed to add a special message to specify
> the ROI in absolute values and [pix_roi] would then normalize the
> values internally.
>
> fgmadr
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlDHeHAACgkQkX2Xpv6ydvTIGQCeO2tuvkrwvMWD85eYk7wV17CE
> o6AAoJjTHpoqTjp+UDuiK95zQHiWDbIm
> =8jSq
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From zmoelnig at iem.at  Tue Dec 11 19:48:44 2012
From: zmoelnig at iem.at (=?ISO-8859-15?Q?IOhannes_m_zm=F6lnig?=)
Date: Tue, 11 Dec 2012 19:48:44 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNcjnZ=+jgNtQ=1C2hmNWzqTkBJ_kJXuCxP9po8ubWqBfQ@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
	<50C774B6.4040701@iem.at> <50C77870.6020003@iem.at>
	<CAGn5wNcjnZ=+jgNtQ=1C2hmNWzqTkBJ_kJXuCxP9po8ubWqBfQ@mail.gmail.com>
Message-ID: <50C7800C.5070804@iem.at>

On 12/11/2012 19:24, Antoine Villeret wrote:
> and what about the opposite ?
> stay in discrete coordinate in the code and add a normalized message ?
> in that way the conversion is done only once (when the ROI is set in
> normalized coord) and not each time we set the data (for pix_set)
> maybe i'm going wrong...

i'd rather not.
the way it is now, [pix_roi] is independent of the actual pixes.
i very much like it that way.

one could provide helper-functions to easily convert a given ROI/pix to 
absolute coordinates on the C++ layer, if you care about the programming 
overhead.
the computational overhead is small enough.


fgmasdr
IOhannes


From antoine.villeret at gmail.com  Tue Dec 11 20:38:15 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Tue, 11 Dec 2012 20:38:15 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C7800C.5070804@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
	<50C774B6.4040701@iem.at> <50C77870.6020003@iem.at>
	<CAGn5wNcjnZ=+jgNtQ=1C2hmNWzqTkBJ_kJXuCxP9po8ubWqBfQ@mail.gmail.com>
	<50C7800C.5070804@iem.at>
Message-ID: <CAGn5wNf8N+ACYWLS1kZesYYVAFQJx4mMJUMsZQahfL1KQ4fVqA@mail.gmail.com>

ok you're the boss :-)

about the pix_set, i had a fill method which doesn't care about the ROI
should it ?

+
a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/11 IOhannes m zm?lnig <zmoelnig at iem.at>:
> On 12/11/2012 19:24, Antoine Villeret wrote:
>>
>> and what about the opposite ?
>> stay in discrete coordinate in the code and add a normalized message ?
>> in that way the conversion is done only once (when the ROI is set in
>> normalized coord) and not each time we set the data (for pix_set)
>> maybe i'm going wrong...
>
>
> i'd rather not.
> the way it is now, [pix_roi] is independent of the actual pixes.
> i very much like it that way.
>
> one could provide helper-functions to easily convert a given ROI/pix to
> absolute coordinates on the C++ layer, if you care about the programming
> overhead.
> the computational overhead is small enough.
>
>
> fgmasdr
> IOhannes
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From zmoelnig at iem.at  Tue Dec 11 21:00:44 2012
From: zmoelnig at iem.at (=?ISO-8859-15?Q?IOhannes_m_zm=F6lnig?=)
Date: Tue, 11 Dec 2012 21:00:44 +0100
Subject: [GEM-dev] pix_set new features
In-Reply-To: <CAGn5wNf8N+ACYWLS1kZesYYVAFQJx4mMJUMsZQahfL1KQ4fVqA@mail.gmail.com>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
	<50C774B6.4040701@iem.at> <50C77870.6020003@iem.at>
	<CAGn5wNcjnZ=+jgNtQ=1C2hmNWzqTkBJ_kJXuCxP9po8ubWqBfQ@mail.gmail.com>
	<50C7800C.5070804@iem.at>
	<CAGn5wNf8N+ACYWLS1kZesYYVAFQJx4mMJUMsZQahfL1KQ4fVqA@mail.gmail.com>
Message-ID: <50C790EC.3010704@iem.at>

On 12/11/2012 20:38, Antoine Villeret wrote:
>
> about the pix_set, i had a fill method which doesn't care about the ROI
> should it ?
>

i dunno, so i left in untouched.
i guess, it would make sense if ROI applied to the fill as well.

fgamdsr
IOhannes


From cgclepper at gmail.com  Tue Dec 11 23:32:23 2012
From: cgclepper at gmail.com (chris clepper)
Date: Tue, 11 Dec 2012 17:32:23 -0500
Subject: [GEM-dev] pix_set new features
In-Reply-To: <50C7800C.5070804@iem.at>
References: <CAGn5wNfO8+T-oAcCfrf283vZ7aAdiF2dffiZfoAbFJzyPVRarQ@mail.gmail.com>
	<50C1DD94.8010705@iem.at>
	<CAGn5wNect8T711B9PKR9=LfTRZZGzsWVFFom2qTZ1FyLZDKgSQ@mail.gmail.com>
	<50C6F508.5080302@iem.at>
	<CAGn5wNcvdeg4++p4ZDY395Ke2coWNuxFao5eT1JoJyy7hjcDdg@mail.gmail.com>
	<50C7670D.8040107@iem.at>
	<CAGn5wNfQPd2LQbGAKJVURMqinMkmhbdVOXN94LjrVm2hNMGLkA@mail.gmail.com>
	<50C774B6.4040701@iem.at> <50C77870.6020003@iem.at>
	<CAGn5wNcjnZ=+jgNtQ=1C2hmNWzqTkBJ_kJXuCxP9po8ubWqBfQ@mail.gmail.com>
	<50C7800C.5070804@iem.at>
Message-ID: <CAEbEQW2T7ft3zkF-NiaLS6EC5fAYzSfNO=G8OV15BH8L2VCvTA@mail.gmail.com>

On Tue, Dec 11, 2012 at 1:48 PM, IOhannes m zm?lnig <zmoelnig at iem.at> wrote:

>
>
> one could provide helper-functions to easily convert a given ROI/pix to
> absolute coordinates on the C++ layer, if you care about the programming
> overhead.
> the computational overhead is small enough.
>
>
It should be easy enough to do this on the patcher level with pix_info,
pix_film outlet etc. right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20121211/c61ae60f/attachment.htm>

From antoine.villeret at gmail.com  Wed Dec 12 17:46:33 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Wed, 12 Dec 2012 17:46:33 +0100
Subject: [GEM-dev] pix_opencv
Message-ID: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>

hello,

i realize that pix_opencv is not include anywhere and people have to
search it in the SVN and to built it themselves

i'm wondering how we can help them to use this library
i think it's a bit difficult to rewrite it's build system to fit the
template because of the dependencies on Gem and OpenCV

but could it possible to include this library in Gem ? in the extras ?
like pix_fiducial and others ?

what do you think about that ?

+
a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


From hans at at.or.at  Wed Dec 12 19:19:04 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Wed, 12 Dec 2012 13:19:04 -0500
Subject: [GEM-dev] pix_opencv
In-Reply-To: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
Message-ID: <55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>


I think the best way to make it easy to find, download and install is to make binaries structured as libdirs and post them on puredata.info/downloads.

I think with a little work that we can make a Gem external template based on the Library Template.  I've done it before quick and dirty, that's not hard.

.hc

On Dec 12, 2012, at 11:46 AM, Antoine Villeret wrote:

> hello,
> 
> i realize that pix_opencv is not include anywhere and people have to
> search it in the SVN and to built it themselves
> 
> i'm wondering how we can help them to use this library
> i think it's a bit difficult to rewrite it's build system to fit the
> template because of the dependencies on Gem and OpenCV
> 
> but could it possible to include this library in Gem ? in the extras ?
> like pix_fiducial and others ?
> 
> what do you think about that ?
> 
> +
> a
> --
> do it yourself
> http://antoine.villeret.free.fr
> http://drii.ensad.fr
> --
> Google lit ce mail...
> si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
> pour me contacter
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev



From antoine.villeret at gmail.com  Wed Dec 12 19:42:04 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Wed, 12 Dec 2012 19:42:04 +0100
Subject: [GEM-dev] [PD-dev]  pix_opencv
In-Reply-To: <20121212183406.GK3036@fuzz.ucsd.edu>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
Message-ID: <CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>

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

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

+
a
--
do it yourself
http://antoine.villeret.free.fr
http://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
pour me contacter


2012/12/12 Miller Puckette <msp at ucsd.edu>:
> I tried and was able to make Gem externals that worked on linux and
> Mac OS, but on Windows I wasn't able to link eternals that needed Gem symbols.
> This was years ago though, and anyway I might have been missing something :)
>
> m
>
> On Wed, Dec 12, 2012 at 01:19:04PM -0500, Hans-Christoph Steiner wrote:
>>
>> I think the best way to make it easy to find, download and install is to make binaries structured as libdirs and post them on puredata.info/downloads.
>>
>> I think with a little work that we can make a Gem external template based on the Library Template.  I've done it before quick and dirty, that's not hard.
>>
>> .hc
>>
>> On Dec 12, 2012, at 11:46 AM, Antoine Villeret wrote:
>>
>> > hello,
>> >
>> > i realize that pix_opencv is not include anywhere and people have to
>> > search it in the SVN and to built it themselves
>> >
>> > i'm wondering how we can help them to use this library
>> > i think it's a bit difficult to rewrite it's build system to fit the
>> > template because of the dependencies on Gem and OpenCV
>> >
>> > but could it possible to include this library in Gem ? in the extras ?
>> > like pix_fiducial and others ?
>> >
>> > what do you think about that ?
>> >
>> > +
>> > a
>> > --
>> > do it yourself
>> > http://antoine.villeret.free.fr
>> > http://drii.ensad.fr
>> > --
>> > Google lit ce mail...
>> > si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr
>> > pour me contacter
>> >
>> > _______________________________________________
>> > GEM-dev mailing list
>> > GEM-dev at iem.at
>> > http://lists.puredata.info/listinfo/gem-dev
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev


From zmoelnig at iem.at  Thu Dec 13 09:43:06 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Thu, 13 Dec 2012 09:43:06 +0100
Subject: [GEM-dev] [PD-dev]  pix_opencv
In-Reply-To: <CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
Message-ID: <50C9951A.9080502@iem.at>

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

caveat:
both Gem and pix-opencv are complex projects. Gem has slow release
cycles, those of pix-opencv seems to be even more so.
synchronizing both projects so that we can create a "stable"
Gem-package including a "stable" pix-opencv could be impossible.

so in a way it would be better if pix-opencv was distributed
separately, but actively.



fgmasdr
Ihannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDJlRcACgkQkX2Xpv6ydvRQ0gCguxWsVlMU838wbLxW9zs0px4W
rmwAn2vf35asYl+NRTwxs+FXjtrWCzhk
=HCe3
-----END PGP SIGNATURE-----


From stefffens at googlemail.com  Thu Dec 13 15:37:02 2012
From: stefffens at googlemail.com (Steffen Kraska)
Date: Thu, 13 Dec 2012 15:37:02 +0100
Subject: [GEM-dev] Memory leak in pix_film /pix_movie
Message-ID: <50C9E80E.7050903@googlemail.com>

Hello,
i am currently working on a patch that,
loads random movie samples into gemwin via pix_film. i reconized memory 
related crashes,
that seem to originate in a memory leak in pix_film.
i could reproduce the error with the pix_film helpfile. If you look at 
pd's used memory,
it increases everytime you load a new file and it does not flush, or get 
empty again.
so my pd crashes arround 3GB of ram used
my system is a mba 2012 with 8gb ram. pd is 0.42.5 extended (standart 
download from the website).
is there some way to unload the movie, or clear the memory ?
any help would be apreciated.
greetings
steffen



From zmoelnig at iem.at  Thu Dec 13 16:21:29 2012
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Thu, 13 Dec 2012 16:21:29 +0100
Subject: [GEM-dev] Memory leak in pix_film /pix_movie
In-Reply-To: <50C9E80E.7050903@googlemail.com>
References: <50C9E80E.7050903@googlemail.com>
Message-ID: <50C9F279.2040608@iem.at>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-12-13 15:37, Steffen Kraska wrote:
> Hello, i am currently working on a patch that, loads random movie
> samples into gemwin via pix_film. i reconized memory related
> crashes, that seem to originate in a memory leak in pix_film. i
> could reproduce the error with the pix_film helpfile. If you look
> at pd's used memory, it increases everytime you load a new file and
> it does not flush, or get empty again. so my pd crashes arround 3GB
> of ram used my system is a mba 2012 with 8gb ram. pd is 0.42.5
> extended (standart download from the website). is there some way to
> unload the movie, or clear the memory ? any help would be
> apreciated.

could you please provide more information about your system?
e.g.
which operating system?
which version of Gem (i don't track which version of Gem is included
in which version of PdX)?
which video-backends are installed / are you using?

you can find most of this information in the Pd-Console.


if you are using w32, there is a known file-handle leak (but not a
memory leak!) which is unfixable with Pd<=0.43.

fgamd
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDJ8nQACgkQkX2Xpv6ydvQMjQCeMuJgz9s+UK+/oYFOhs+BWArv
RUAAnj45EpAlEpDUAcM6VlBysKQ3x3N1
=ir5A
-----END PGP SIGNATURE-----


From hans at at.or.at  Thu Dec 13 17:01:26 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Thu, 13 Dec 2012 11:01:26 -0500
Subject: [GEM-dev] [PD-dev]  pix_opencv
In-Reply-To: <50C9951A.9080502@iem.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
Message-ID: <51FAFAFD-62C6-4BBA-B397-1274429ED06C@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.

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

> caveat:
> both Gem and pix-opencv are complex projects. Gem has slow release
> cycles, those of pix-opencv seems to be even more so.
> synchronizing both projects so that we can create a "stable"
> Gem-package including a "stable" pix-opencv could be impossible.
> 
> so in a way it would be better if pix-opencv was distributed
> separately, but actively.


I agree, lumping everything into one giant package makes it into a maintenance headache and centralizes that headache on IOhannes, since he's the lead maintainer of Gem.  Its good to avoid it.

.hc

From stefffens at googlemail.com  Thu Dec 13 17:24:58 2012
From: stefffens at googlemail.com (Steffen Kraska)
Date: Thu, 13 Dec 2012 17:24:58 +0100
Subject: [GEM-dev] Memory leak in pix_film /pix_movie
In-Reply-To: <50C9F279.2040608@iem.at>
References: <50C9E80E.7050903@googlemail.com> <50C9F279.2040608@iem.at>
Message-ID: <50CA015A.6010509@googlemail.com>

hello,
thanks for the answer.
my sytem :
macbook air 2012
core i5 1,8 ghz
8gb ram
OSX 10.8.2

pd-extended (copyed from console )
[import] $Revision: 1.2 $
     [import] is still in development, the interface could change!
     compiled against Pd version 0.42.5
libdir loader $Revision: 1.8 $
     compiled on Sep 22 2010 at 03:41:35
     compiled against Pd version 0.42.5.extended
GEM: Graphics Environment for Multimedia
GEM: ver: 0.92.3
GEM: compiled: Sep 22 2010
GEM: maintained by IOhannes m zmoelnig
GEM: Authors :    Mark Danks (original version)
GEM:        Chris Clepper
GEM:        Cyrille Henry
GEM:        IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, 
Hans-Christop Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM:     homepage http://gem.iem.at/
GEM:     bug-tracker http://sourceforge.net/projects/pd-gem/
GEM:     mailing-list http://lists.puredata.info/listinfo/gem-dev/
GEM: compiled for SIMD architecture: SSE2 MMX
GEM: using SSE2 optimization

i dont know what video backend means, i have quicktime and vlc 
installed, for output i use the Macbook screen.

greetings
steffen

> IOhannes m zmoelnig <mailto:zmoelnig at iem.at>
> December 13, 2012 4:21 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> could you please provide more information about your system?
> e.g.
> which operating system?
> which version of Gem (i don't track which version of Gem is included
> in which version of PdX)?
> which video-backends are installed / are you using?
>
> you can find most of this information in the Pd-Console.
>
>
> if you are using w32, there is a known file-handle leak (but not a
> memory leak!) which is unfixable with Pd<=0.43.
>
> fgamd
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlDJ8nQACgkQkX2Xpv6ydvQMjQCeMuJgz9s+UK+/oYFOhs+BWArv
> RUAAnj45EpAlEpDUAcM6VlBysKQ3x3N1
> =ir5A
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
> Steffen Kraska <mailto:stefffens at googlemail.com>
> December 13, 2012 3:37 PM
> Hello,
> i am currently working on a patch that,
> loads random movie samples into gemwin via pix_film. i reconized 
> memory related crashes,
> that seem to originate in a memory leak in pix_film.
> i could reproduce the error with the pix_film helpfile. If you look at 
> pd's used memory,
> it increases everytime you load a new file and it does not flush, or 
> get empty again.
> so my pd crashes arround 3GB of ram used
> my system is a mba 2012 with 8gb ram. pd is 0.42.5 extended (standart 
> download from the website).
> is there some way to unload the movie, or clear the memory ?
> any help would be apreciated.
> greetings
> steffen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20121213/4989e710/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20121213/4989e710/attachment.jpg>

From antoine.villeret at gmail.com  Thu Dec 13 18:21:10 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Thu, 13 Dec 2012 18:21:10 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
Message-ID: <CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>

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

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 ?

>
>> caveat:
>> both Gem and pix-opencv are complex projects. Gem has slow release
>> cycles, those of pix-opencv seems to be even more so.
>> synchronizing both projects so that we can create a "stable"
>> Gem-package including a "stable" pix-opencv could be impossible.
>>
>> so in a way it would be better if pix-opencv was distributed
>> separately, but actively.
>
>
> I agree, lumping everything into one giant package makes it into a maintenance headache and centralizes that headache on IOhannes, since he's the lead maintainer of Gem.  Its good to avoid it.

i do agree too, but I think it could be good to distribute pix_opencv
with Gem whenever it's possible and not too hurting for your head :-)

a.

>
> .hc
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From hans at at.or.at  Thu Dec 13 19:38:26 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Thu, 13 Dec 2012 13:38:26 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
Message-ID: <7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@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




From noreply at sourceforge.net  Fri Dec 14 10:43:44 2012
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 14 Dec 2012 01:43:44 -0800
Subject: [GEM-dev] [ pd-gem-Bugs-3595874 ] extremely high cpu usage when
	using GEM in a tiling wm
Message-ID: <mailman.307.1355478261.2527.gem-dev@iem.at>

Bugs item #3595874, was opened at 2012-12-14 01:43
Message generated for change (Tracker Item Submitted) made by defaultxr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3595874&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: rendering (e.g. display)
Group: linux
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: defaultxr (defaultxr)
Assigned to: Nobody/Anonymous (nobody)
Summary: extremely high cpu usage when using GEM in a tiling wm

Initial Comment:
I use a window manager called StumpWM, and the default behavior of the window manager is to maximize all windows within their "frame". when i try to open a gem window via the [gemwin] object, the window manager and GEM get stuck in a "resizing fight", with the window manager attempting to resize the GEM window, and GEM attempting to reset the size. it works fine if i use a floating window group (which does not cause the window manager to try resizing the window), but i prefer not to have to do that. it also works if i send a "dimen" message to [gemwin] with the precise dimensions that StumpWM will try to resize the window to, but if i attempt to split the window-frame, the problem comes back.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3595874&group_id=64325


From antonio at hellocatfood.com  Wed Dec 26 18:23:28 2012
From: antonio at hellocatfood.com (Antonio Roberts)
Date: Wed, 26 Dec 2012 17:23:28 +0000
Subject: [GEM-dev] pix_record continues to record,
	even with rendering turned off
Message-ID: <CAOkiBYiWe6vjSyMYjD2+72BG1dCnrKnbD+UzZ1Z5LA-EAEtUgA@mail.gmail.com>

I've noticed that [pix_record] will continue to record frames even if
the [gemhead] object attached to it is switched off. Is this a bug?

I've attached a sample patch, where I'm attempting to take a snapshot
from a camera and save it to a video

#N canvas 1660 101 564 374 10;
#X obj 281 40 gemwin;
#X obj 39 118 gemhead;
#X obj 39 148 pix_video;
#X obj 39 177 pix_texture;
#X obj 39 205 rectangle 4 3;
#X obj 39 88 metro 10;
#X obj 39 59 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1
;
#X msg 281 10 buffer 1 \, create \, 1;
#X msg 189 165 record \$1;
#X obj 189 143 tgl 15 0 empty empty empty 17 7 0 10 -257985 -1 -1 0
1;
#X msg 137 44 0;
#X obj 39 28 loadbang;
#X obj 39 285 pix_record;
#X floatatom 67 315 5 0 0 0 - - -;
#X obj 67 334 change;
#X msg 189 205 1;
#X msg 189 105 file ./test.mov;
#X text 292 104 1- open file;
#X text 292 164 2- start record;
#X text 292 204 3- capture frame;
#X text 422 164 4- stop record;
#X text 182 284 Despite rendering not being on \, the pix record object
continues to record until it is turned off. A bug?;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 4 0 12 0;
#X connect 5 0 1 0;
#X connect 6 0 5 0;
#X connect 7 0 0 0;
#X connect 8 0 12 0;
#X connect 9 0 8 0;
#X connect 10 0 6 0;
#X connect 11 0 6 0;
#X connect 12 1 13 0;
#X connect 13 0 14 0;
#X connect 14 0 10 0;
#X connect 15 0 6 0;
#X connect 16 0 12 0;

-- 
============================
antonio at hellocatfood.com
http://www.hellocatfood.com
============================


From antoine.villeret at gmail.com  Wed Dec 26 21:11:15 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Wed, 26 Dec 2012 21:11:15 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
Message-ID: <CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>

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


From hans at at.or.at  Thu Dec 27 05:15:06 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Wed, 26 Dec 2012 23:15:06 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
Message-ID: <A4F451C2-319B-44D5-8164-29D1B278B08C@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.

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

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

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

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



From antoine.villeret at gmail.com  Thu Dec 27 15:30:32 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Thu, 27 Dec 2012 15:30:32 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
Message-ID: <CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>

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


From hans at at.or.at  Thu Dec 27 15:55:06 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Thu, 27 Dec 2012 09:55:06 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
Message-ID: <EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@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
>>>> 
>>>> 
>> 



From antoine.villeret at gmail.com  Thu Dec 27 16:03:14 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Thu, 27 Dec 2012 16:03:14 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
Message-ID: <CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>

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


From hans at at.or.at  Thu Dec 27 16:18:53 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Thu, 27 Dec 2012 10:18:53 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
Message-ID: <1263E308-B454-41BE-BC17-1D362AB4F661@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
>>>>>> 
>>>>>> 
>>>> 
>> 



From antoine.villeret at gmail.com  Thu Dec 27 16:35:12 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Thu, 27 Dec 2012 16:35:12 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
Message-ID: <CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>

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


From zmoelnig at iem.at  Thu Dec 27 18:49:08 2012
From: zmoelnig at iem.at (=?ISO-8859-15?Q?IOhannes_m_zm=F6lnig?=)
Date: Thu, 27 Dec 2012 18:49:08 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
Message-ID: <50DC8A14.7050009@iem.at>

On 12/27/2012 16:03, Antoine Villeret wrote:
> the default make install command from git repo install gem into
> /usr/local/include

how about using pkg-config?
Gem installs a "Gem.pc" file, so you should do something like
CFLAGS_linux = `pkg-config --cflags opencv Gem`


fgmsdar
IOhannes


From antoine.villeret at gmail.com  Thu Dec 27 19:49:08 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Thu, 27 Dec 2012 19:49:08 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <50DC8A14.7050009@iem.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<50DC8A14.7050009@iem.at>
Message-ID: <CAGn5wNdgPVmTCC_JUPJvu2O8T0BoNOxmoHeodmnQYJ0efe5xew@mail.gmail.com>

cool ! shame on me, I didn't know this feature of Gem
Makefile is updated in the SVN according to that

+
a
--
do it yourself
http://antoine.villeret.free.fr


2012/12/27 IOhannes m zm?lnig <zmoelnig at iem.at>:
> On 12/27/2012 16:03, Antoine Villeret wrote:
>>
>> the default make install command from git repo install gem into
>> /usr/local/include
>
>
> how about using pkg-config?
> Gem installs a "Gem.pc" file, so you should do something like
> CFLAGS_linux = `pkg-config --cflags opencv Gem`
>
>
> fgmsdar
> IOhannes
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


From hans at at.or.at  Thu Dec 27 21:36:24 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Thu, 27 Dec 2012 15:36:24 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
	<CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>
Message-ID: <40053801-7DCA-4199-8FAA-970750E3D6DF@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 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
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>> 



From antoine.villeret at gmail.com  Fri Dec 28 13:20:12 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Fri, 28 Dec 2012 13:20:12 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <40053801-7DCA-4199-8FAA-970750E3D6DF@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
	<CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>
	<40053801-7DCA-4199-8FAA-970750E3D6DF@at.or.at>
Message-ID: <CAGn5wNf8kYv71MVAQ_4bXKkXqBrAdTgym=j=JpKRygZq4Ymj+w@mail.gmail.com>

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


From hans at at.or.at  Fri Dec 28 14:37:32 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Fri, 28 Dec 2012 08:37:32 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <CAGn5wNf8kYv71MVAQ_4bXKkXqBrAdTgym=j=JpKRygZq4Ymj+w@mail.gmail.com>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
	<CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>
	<40053801-7DCA-4199-8FAA-970750E3D6DF@at.or.at>
	<CAGn5wNf8kYv71MVAQ_4bXKkXqBrAdTgym=j=JpKRygZq4Ymj+w@mail.gmail.com>
Message-ID: <50DDA09C.2050809@at.or.at>


Post a request to pd-dev and send your ssh key, here are the details:
http://puredata.info/docs/developer/PdLab

.hc

On 12/28/2012 07:20 AM, Antoine Villeret wrote:
> 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 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 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>


From antoine.villeret at gmail.com  Sat Dec 29 13:02:07 2012
From: antoine.villeret at gmail.com (Antoine Villeret)
Date: Sat, 29 Dec 2012 13:02:07 +0100
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <50DDA09C.2050809@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
	<CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>
	<40053801-7DCA-4199-8FAA-970750E3D6DF@at.or.at>
	<CAGn5wNf8kYv71MVAQ_4bXKkXqBrAdTgym=j=JpKRygZq4Ymj+w@mail.gmail.com>
	<50DDA09C.2050809@at.or.at>
Message-ID: <CAGn5wNf4EqqSq6Mw8rGFpztOa=wrs=HKrfjW7F8gCEVUafkBpA@mail.gmail.com>

ok cool
but puredata.info seems to be down now...
I'll try agan later

thanks

a
--
do it yourself
http://antoine.villeret.free.fr


2012/12/28 Hans-Christoph Steiner <hans at at.or.at>:
>
> Post a request to pd-dev and send your ssh key, here are the details:
> http://puredata.info/docs/developer/PdLab
>
> .hc
>
> On 12/28/2012 07:20 AM, Antoine Villeret wrote:
>> 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 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 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>


From hans at at.or.at  Mon Dec 31 18:28:44 2012
From: hans at at.or.at (Hans-Christoph Steiner)
Date: Mon, 31 Dec 2012 12:28:44 -0500
Subject: [GEM-dev] [PD-dev] pix_opencv
In-Reply-To: <40053801-7DCA-4199-8FAA-970750E3D6DF@at.or.at>
References: <CAGn5wNe5O+VfdpufHDQPrwKW3O-dHm-gb6bAhWa5r=fNeXEaow@mail.gmail.com>
	<55CD7B0B-E596-4B6A-86C9-EC43905D44A0@at.or.at>
	<20121212183406.GK3036@fuzz.ucsd.edu>
	<CAGn5wNdC+w635tjUUke16rWgDFApC+5thpQhUVEKu1o0JeKZ_g@mail.gmail.com>
	<50C9951A.9080502@iem.at>
	<51FAFAFD-62C6-4BBA-B397-1274429ED06C@at.or.at>
	<CAGn5wNcnNCJ0Z2BET5tmeTtO0bvtYy3gw_=emfmLSFO-fadLYw@mail.gmail.com>
	<7FC2F52F-61E0-4443-BAC0-AD50C3D8BF7C@at.or.at>
	<CAGn5wNeBRxD+q=TiS_JnWS8n62npBdjo42u+1VMtugTjYnUjAg@mail.gmail.com>
	<A4F451C2-319B-44D5-8164-29D1B278B08C@at.or.at>
	<CAGn5wNeDg3+UG3ZCfOcsZ76=kRgUcN9JupbBj8Kqa6TFkp=G_Q@mail.gmail.com>
	<EA672EFD-2EF9-4D2C-BB9C-F041B5F669C9@at.or.at>
	<CAGn5wNeC=Y76f_zqjDVStV-V1edgkaZo=sxEfh1WZBp57bMTLQ@mail.gmail.com>
	<1263E308-B454-41BE-BC17-1D362AB4F661@at.or.at>
	<CAGn5wNew4vbK7foNb86_FxV4FB1cP+_Dyw-Vfpu=L0La5SAsWA@mail.gmail.com>
	<40053801-7DCA-4199-8FAA-970750E3D6DF@at.or.at>
Message-ID: <9B4ED4E1-0E34-492A-A152-CD83401D982A@at.or.at>


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