13 messages in at.iem.pd-dev[PD-dev] Re: [GEM] pix_blur ???? whic...| From | Sent On | Attachments |
|---|---|---|
| IOhannes zmoelnig | Feb 19, 2003 12:07 pm | |
| chris clepper | Feb 19, 2003 6:21 pm | |
| bbogart | Feb 20, 2003 8:37 am | |
| zmoe...@iem.at | Feb 21, 2003 12:38 am | |
| guenter geiger | Feb 21, 2003 3:33 am | |
| Me | Feb 21, 2003 7:36 am | |
| Matthew Allen | Feb 21, 2003 10:10 am | |
| chris clepper | Feb 21, 2003 10:47 am | |
| chris clepper | Feb 21, 2003 11:58 am | |
| IOhannes zmoelnig | Feb 24, 2003 2:48 am | |
| guenter geiger | Feb 24, 2003 5:33 am | |
| chris clepper | Feb 24, 2003 11:00 am | |
| IOhannes zmoelnig | Feb 24, 2003 11:29 am |
| Subject: | [PD-dev] Re: [GEM] pix_blur ???? which Gem-objects do we need (have) ? | |
|---|---|---|
| From: | zmoe...@iem.at (zmoe...@iem.at) | |
| Date: | Feb 21, 2003 12:38:40 am | |
| List: | at.iem.pd-dev | |
Zitiere chris clepper <ccle...@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