[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