[PD-dev] Re: [GEM] pix_blur ???? which Gem-objects do we need (have) ?

zmoelnig at iem.at zmoelnig at iem.at
Fri Feb 21 09:39:02 CET 2003


Zitiere chris clepper <cclepper at artic.edu>:

> well you sort of answered your own question, but here's the breakdown:
> 
> - pix_blur is faster, more direct and perhaps easier to use if you 
> just want to blur something
> - tv_biquad is slower and may be harder to use depending on your 
> understanding of filters
> 
> 
> this is not stated anywhere, and this is the first info on tv_* that 
> i have seen.  i have ignored them until now, especially after the too 
> long yuv vs pix debate, where 'everything should be pix_' was the 
> result.
yes indeed: i'm not happy with [tv_*] at all. (and i hate arguing it because of 
this pix_* vs yuv_* again ;-))
i thought i had "documented" this in the WHATSNEW-file. (but of course, these 
should be read)

> that's a good suggestion.  both can be used  for [pix_blur] with only 
> a small change to the code.
yes i know, but i just wanted to make clear that we should make objects that 
allow "all" parameters to be specified by the user and not relying on "good 
defaults". I really hate those consumer-software that does not allow you to do 
anything but choose the filename for your "project".

> 
> ok this is a HUGE difference in our approaches.  i would never assume 
obviously.

> that anyone using GEM would know how to program a convolution kernel 
yes, there are different approaches...

> or openGL, and that shouldn't prevent them from using these things. 
> i actually intend on making [pix_edgedetect] and [pix_sharpen] at 
> some point because those are process that people like to do on 
> images, whether or not they even know that they are just variations 
> on the same mathematical formula.
but i don't think that this should be built-in objects.
Why not make a simple abstraction that can do this ? And make this abstraction 
available from within pd: So dummy-users (consumers) could use these without 
having to worry about convolution-kernels. "Power-users" (urgh!) could use the 
convolution kernel.

By the way, i think the example for convolution makes it somehow clear, what 
can be done with it (but of course, i have some knowledge of dsp)
maybe other people are afraid of names like "convolution" and "fft".

> this goes back to the reason i even got involved with GEM in the 
> first place, which was to help  make a high-performance Mac OSX 
> version of the software for ARTISTS to use.  that means 'ready-made' 
> tools need to be available, most of these tools GEM lacks at the 
> moment.  you might consider something like photoshop's sharpen/blur 
> to be 'folkloristic', but this is how these processes are referred to 
of course you are right.
But why not implementing these as abstractions ?
you don't build externals for "+ 1" and "+ 2", do you ? (very stupid example, 
and i have no abstraction ready at hand for incrementing a value everytime i 
need it too - and i repeatedly think of making an external for this --- but i 
don't do it)

> in common practice.  i don't see any reason why both the lower level 
> [pix_convolve] can't exist alongside the more abstracted 
> [pix_sharpen/blur] objects.  if anything the latter is more direct 
> and understandable to the larger number of users.  the abstractions 
> are one way to go but the higher level objects C code can be 
> optimized for each specific kernel.
true. true. but:
i do not see any major optimization for sharpening vs. bluring since they are 
basically the very same thing (in terms of filtering).
The main reasons against built-in's are:
*) there is no end to it!
*) the user's won't learn something (as long as they are not studying the code)

maybe some users have earned a deeper (or a first) understanding of signal-
processing because of the way pd works. They learned how effects are made (vs. 
applied). I want the same for Gem-users.
I fear users asking for features like "sharpening" when it is already there.
And they will go and ask for "sharpening more" (is called like this in 
photoshop ?). And i am not willing to spend my time for these. (but of course, 
that is quite arrogant)

> but i really really really would like to hear what users of GEM and 
> people interested in GEM have to say about things like this.

mfg.as.r
IOhannes




More information about the Pd-dev mailing list