[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