[PD] pix_set / pix_gain weirdness

Matteo Sisti Sette matteosistisette at gmail.com
Sun Feb 27 19:35:57 CET 2011


On 02/27/2011 06:43 PM, Mathieu Bouchard wrote:
> On Mon, 31 Jan 2011, Matteo Sisti Sette wrote:
>
>> However by trying it a little bit I got the impression that any
>> real-life image processing of even a minimum of complexity is
>> completely unfeasible in practice because it immediately becomes too
>> slow. Or isn't it so? Is it possible, for example, to do movement
>> detection and blob detection in gridflow with an efficiency even
>> remotely comparable to that you can achieve with [pix_movement] and
>> [pix_blob]?

> I don't know, I never tried those.
>
> Are you trying it with an image size much larger than what you really
> need to analyse ?

No I wan't, but I haven't really tried blob detection. I just tried some 
very basic image processing such as mixing two images, changing the 
colors, you know the basic stuff you can find in the example patches, 
and the CPU was already very loaded with relatively small images.


> The pixel throughput isn't everything... it's what you do with it.

Of course. I'm sure there are a lot of fascinating things that can be 
done with low (or not-so-high) pixel throughput.


And by the way I didn't mean to criticize GridFlow in any way. I was 
just expressing the fact that the power of manipulating raw pixels with 
matrices in a patching environment such as Pd results to me 
"frustratingly attractive", where the frustration comes from the fact 
that you can't achieve enough efficiency to manipulate images of 
"reasonable size" (where of course reasonable means reasonable to me in 
a given context, e.g. a 1024x768 image to be projected). But I think the 
limitation is mostly intrinsic in the fact of doing it in an 
"interpreted" environment.
I mean I don't think gridflow could be much faster than it is, or could it?


> And measuring GridFlow in terms of what GEM allows you to do won't
> reveal what GridFlow can offer you that GEM can't.

Of course, mine was not meant to be a fair comparison ;)


Something that would be great would be a "pd/gridflow-like" patching 
environment that would compile your patch into shaders and have the GPU 
make the computation - but in a completely invisible way ....

Do you know if something like that already exists?



More information about the Pd-list mailing list