well, for those interested...but maybe it's a dev subject...
On 2 oct. 09, at 18:46, ydegoyon@gmail.com wrote:
estimado Loic,
i don't have an idea of what you men by 'Jean Yves implementation'. i never saw it posted anywhere and where is the code?
here is Jean-Yves's stuff,it has been posted on the pd-list :
Projet CVlib : openCV (computer vision lib) dans pure data | Free ...
- [ Translate this page ]
21 fév 2009 ... Le projet CvLib consiste en un framework de
développement multiplateformes pour faciliter l'implémentation dans
Pure Data des ...
s184785159.onlinehome.fr/drupal/?q=node/167 - Cached - Similar
i
apart from this we try to make things easy for the people and not a head-breaking library like gridflow is. and that can only be used by scientifics..
yes, I see, this is an important thing, of course.
tom schouten already went in that direction and i totally disagree with it
what do you mean by this? are you talking about pdp? Is pdp send a
pointer from one external to another ?
later, loic
ciao, sevy
Loic Kessous wrote:
Dear Lluis and Yves,
I'm reading your paper about openCV from the pdconf, and I was
thinking about a few things that I'd like to share with you.Some month ago I work on a project with pd and openCV and I observe
that there was quit different approaches...with different advantage regarding platforms and implementations,
including the use of flext o not apparently also.I recompiled and test for different purposes those different ones:
pix_ , pdp_ and the one from Jean-Yves Gratius, and also some new
experiment from myself (which the idea was to use openCV for
display and video acquisition, this works more or less depending on
the platform and configuration)....this on MSW, Ubuntu and os X..., which tend to show that the
cross-platform issue is not so obvious :)one very interesting thing with Jean-Yves approach is that from one
external to another only a pointer (the one of the OpenCV image) is
passed, and not the full image as (except if I'm confusing) with
pix_ or pdp_ . But this need to compile the external as a full
library (well it is like this in his implementation, I don't know
if there is a issue to avoid this), and understanding the code and
writing new codes is diiferent, I would say more complicated. This may make things more complicated for people who want to
improve the library but just want to add new externals and not deal
with all the lib.He use code:block to compile it, which is both a advantage and an
inconvenient: it took me more sometime to understand it, make link to flex, pd,
gem...but then it is in a way comfortable, and it is cross-platform.I wonder if it should not be possible to keep the idea to pass only
the openCV image pointer (much more efficient) but using an
approach closer to pix_ or pdp_ . From another project, I heard
that there was some work about using shared memory in max and pd
for similar issue. do you have any idea about this?Best,
Loïc
On Fri, 2 Oct 2009, Loic Kessous wrote:
well, for those interested...but maybe it's a dev subject...
Ow... endless potential for nameclashes with GridFlow... maybe there is no clash now, but as both projects use the "cv." prefix together with names spelt exactly as in the original OpenCV, it looks like there will be more clashes in the future.
(at the moment, GridFlow supports very few OpenCV features.)
I will think about a renaming.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 2 Oct 2009, Mathieu Bouchard wrote:
On Fri, 2 Oct 2009, Loic Kessous wrote:
well, for those interested...but maybe it's a dev subject...
Ow... endless potential for nameclashes with GridFlow... maybe there is no clash now, but as both projects use the "cv." prefix together with names spelt exactly as in the original OpenCV, it looks like there will be more clashes in the future.
Ok, I changed it to the "cv/#" prefix.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Loic Kessous wrote:
well, for those interested...but maybe it's a dev subject...
On 2 oct. 09, at 18:46, ydegoyon@gmail.com mailto:ydegoyon@gmail.com wrote:
estimado Loic,
i don't have an idea of what you men by 'Jean Yves implementation'. i never saw it posted anywhere and where is the code?
here is Jean-Yves's stuff,it has been posted on the pd-list : Projet /CVlib/ : openCV (computer vision lib) dans /pure data/ | Free *...* <http://s184785159.onlinehome.fr/drupal/?q=node/167>
- [ Translate this page
21 fév 2009 *...* Le projet /CvLib/ consiste en un framework de développement multiplateformes pour faciliter l'implémentation dans /Pure Data/ des *...* s184785159.onlinehome.fr/drupal/?q=node/167 - Cached http://209.85.229.132/search?q=cache:dYgmEEi9oakJ:s184785159.onlinehome.fr/drupal/%3Fq%3Dnode/167+cvlib+pure+data&cd=1&hl=en&ct=clnk&client=safari - Similar http://www.google.com/search?hl=en&client=safari&rls=en&q=related:s184785159.onlinehome.fr/drupal/%3Fq%3Dnode/167 i
well sorry i did not considered it as it doesn't compile on linux, and no effort was made to make it work there.
i don't know why we should always make the effort to make our stuff made on linux working on windows, and windows people never do the effort ...
massalami, sevy
I understand your point of view, but I am more interested buy the
approach than the implementation itself.
I mean passing a pointer and not the image itself. That's why it's
compiled as a dll library I suppose, and I wonder how using another
solution
as shared memory for example could be done in the same goal...
loic
Well, I must say that after recompiling it on windows, I didn't really
try deeper too on linux or os X.....I will try too.
I don't exactly know how Windows dependent it is.
according to the code not so much, but it uses msvc as compiler if I
well remember.
On 3 oct. 09, at 12:25, ydegoyon@gmail.com wrote:
Loic Kessous wrote:
well, for those interested...but maybe it's a dev subject...
On 2 oct. 09, at 18:46, ydegoyon@gmail.com
mailto:ydegoyon@gmail.com wrote:estimado Loic,
i don't have an idea of what you men by 'Jean Yves implementation'. i never saw it posted anywhere and where is the code?
here is Jean-Yves's stuff,it has been posted on the pd-list : Projet /CVlib/ : openCV (computer vision lib) dans /pure data/ | Free *...* <http://s184785159.onlinehome.fr/drupal/?q=node/167>
- [ Translate this page <http://translate.google.com/translate?hl=en&sl=fr&u=http://s18478515...
]
21 fév 2009 *...* Le projet /CvLib/ consiste en un framework de
développement multiplateformes pour faciliter l'implémentation
dans /Pure Data/ des *...* s184785159.onlinehome.fr/drupal/?q=node/167 - Cached <http://209.85.229.132/search?q=cache:dYgmEEi9oakJ:s184785159.onlinehome.fr/d...i
well sorry i did not considered it as it doesn't compile on linux, and no effort was made to make it work there.
i don't know why we should always make the effort to make our stuff made on linux working on windows, and windows people never do the effort ...
massalami, sevy
On Sat, 3 Oct 2009, Loic Kessous wrote:
I understand your point of view, but I am more interested buy the approach than the implementation itself. I mean passing a pointer and not the image itself.
"Passing the image itself" is largely a myth anyway.
At a first level, Pd doesn't always pass $1, $2, $3, etc., as separate arguments in C: it often passes the pointer to the list (under the name "argv"). This is what always happens for running list-methods and anything-methods, as well as when sending list-messages and anything-messages (pd automatically converts argv to non-argv and non-argv to argv whenever needed).
At a second level, not much large data is passed as pd arglists: some notable exceptions can happen in [pix_data], [pix_set], [#to_list], [#import], [pix_convolve]'s config, Martin's strings, etc.; plugins such as Gem and GridFlow use a second level of pointers to avoid Pd's argv. This is mostly for this reason: because Pd's argv is limited to being a t_atom array, which is usually too big and inefficient for tightly-formatted data, spending 8 or 16 bytes on storing a 4-byte float when you just want to store a single-byte int, for example.
But then, with either level, the way of specifying the pointer to the list allows basically anything to happen, as the pointer doesn't have to be stack allocated. With argv, methods aren't allowed to rely on a past argv after the return is done, but still, the sender of the message can decide the argv to be anything, not necessarily on the stack; this can happen to be fairly permanent data.
Beyond that, there is a distinction between systems that let the user deal with the "pointerness" aspect, and those that try to hide it (to make it more automatic and easier to think about, they pretend to "pass the image" but doesn't really). Outside of Pd, both strategies are widely used. Perl and Tcl are very good examples of strings that never look like they use pointers but always do. In Pd, ... only GridFlow uses something that looks like "pass the image" semantics but has a few gotchas, and it's also the only one that can pass an image without allocating a buffer of the same size as the image. In the end, all the video frameworks make the user mess with pointers in some way:
- Gem's [pix_separator]
- PDP's [pdp_trigger]
- GridFlow's [#t]
- MaPoD even required the user to free() image buffers using a special object-class.
- FrameStein: i don't know (sorry).
That's why it's compiled as a dll library I suppose
I don't see any link between any of the above notions, and the kind of linkage (dll, etc) it uses.
and I wonder how using another solution as shared memory for example could be done in the same goal... loic
No idea what you are referring to. I know what shared memory is, I know what indirection is, but I don't know what is the problem that the solution solves, you didn't say that. (And if anything, shared memory introduces new portability concerns.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
thanks Mathieu, it is still not clear for me what make things faster
in one case or another but it helps.
loic
PS: what do you call Martin's strings ?
On 3 oct. 09, at 23:22, Mathieu Bouchard wrote:
On Sat, 3 Oct 2009, Loic Kessous wrote:
I understand your point of view, but I am more interested buy the
approach than the implementation itself. I mean passing a pointer
and not the image itself."Passing the image itself" is largely a myth anyway.
At a first level, Pd doesn't always pass $1, $2, $3, etc., as
separate arguments in C: it often passes the pointer to the list
(under the name "argv"). This is what always happens for running
list-methods and anything-methods, as well as when sending list- messages and anything-messages (pd automatically converts argv to
non-argv and non-argv to argv whenever needed).At a second level, not much large data is passed as pd arglists:
some notable exceptions can happen in [pix_data], [pix_set],
[#to_list], [#import], [pix_convolve]'s config, Martin's strings,
etc.; plugins such as Gem and GridFlow use a second level of
pointers to avoid Pd's argv. This is mostly for this reason: because
Pd's argv is limited to being a t_atom array, which is usually too
big and inefficient for tightly-formatted data, spending 8 or 16
bytes on storing a 4-byte float when you just want to store a single- byte int, for example.But then, with either level, the way of specifying the pointer to
the list allows basically anything to happen, as the pointer doesn't
have to be stack allocated. With argv, methods aren't allowed to
rely on a past argv after the return is done, but still, the sender
of the message can decide the argv to be anything, not necessarily
on the stack; this can happen to be fairly permanent data.Beyond that, there is a distinction between systems that let the
user deal with the "pointerness" aspect, and those that try to hide
it (to make it more automatic and easier to think about, they
pretend to "pass the image" but doesn't really). Outside of Pd, both
strategies are widely used. Perl and Tcl are very good examples of
strings that never look like they use pointers but always do. In
Pd, ... only GridFlow uses something that looks like "pass the
image" semantics but has a few gotchas, and it's also the only one
that can pass an image without allocating a buffer of the same size
as the image. In the end, all the video frameworks make the user
mess with pointers in some way:
- Gem's [pix_separator]
- PDP's [pdp_trigger]
- GridFlow's [#t]
- MaPoD even required the user to free() image buffers using a
special object-class.
- FrameStein: i don't know (sorry).
That's why it's compiled as a dll library I suppose
I don't see any link between any of the above notions, and the kind
of linkage (dll, etc) it uses.and I wonder how using another solution as shared memory for
example could be done in the same goal... loicNo idea what you are referring to. I know what shared memory is, I
know what indirection is, but I don't know what is the problem that
the solution solves, you didn't say that. (And if anything, shared
memory introduces new portability concerns.)_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 5 Oct 2009, Loic Kessous wrote:
thanks Mathieu, it is still not clear for me what make things faster in one case or another but it helps.
- data spacing: the more your data is spaced in memory, the more the
cache has to load lots of data, because it assumes that the data is not very fragmented. Pd in 64-bit mode spends half of the argv space on padding. Here by spacing I mean the difference of starting position of two elements next to each other (e.g. where are $1 and $2 in RAM).
- data element size: when the data doesn't have padding, this is the same
as data spacing. Pd in in any mode spends half of the nonpadding argv space on type information.
- type checking: if you have to check that every element of an argv is
indeed a float, you need to use twice more data, and it's twice more spacing, but on top of that you need one conditional per element, just in case it isn't a float, and conditionals are getting comparatively slow on modern CPUs because they're harder to accelerate than the rest.
- time fragmentation: a low block size may mean the CPU has to reload
things in the cache more often, if the CPU's other tasks need the same cache for other purposes between the processing of two blocks. Bigger blocks mean that the CPU can "concentrate". Having to repeatedly call, init, deinit, return, is also something that can take time.
- cache fitting: repeatedly making long sweeps on very long arrays can
make the cache completely useless. it's better to do as many things as possible on a small area of RAM at a time.
Based on those five criteria, we could compare various storage and computation strategies of various internals and externals of pd, provided that we get a bit more precise on some things. There may also be additional criteria.
loic PS: what do you call Martin's strings ?
I thought I knew, but I borked that. Martin's strings are [mrpeach/str], but they don't use pd lists of floats, they use a custom atom type called BLOB, which is essentially a form of double-indirection. (POINTER is also a double-indirection, but it was meant for DS, though it's often hijacked to be used in other ways.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 5 Oct 2009, Mathieu Bouchard wrote:
On Mon, 5 Oct 2009, Loic Kessous wrote:
loic PS: what do you call Martin's strings ?
I thought I knew, but I borked that. Martin's strings are [mrpeach/str], but they don't use pd lists of floats, they use a custom atom type called BLOB,
And the weird thing is that actually I knew that very well, but I still wrote «Martin's strings» in the list without thinking, I don't know why. Sleep deprivation, drugs, distractions, name it, blame it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Loic Kessous -
Mathieu Bouchard -
ydegoyon＠gmail.com