Hi list, hi chris.
Maybe a stupid question: What is this [pix_blur] for ? Hey, i don't want to be rude (mr. bad guy again....), but there already is a thing like [tv_biquad] that does very similar things (and more)
I think, Gem should follow pd's (vs. other libraries) object-policy: make a minimum orthogonal object-set, that let's you do "everything" you want. This implies, that there shouldn't be 2 objects, that do basically the same thing. basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is a two-stage feedback-filter.
btw. [tv_*] was meant to "work (only) on series of images", while [pix_*] should work on single images as well. thus [pix_blur] should rather be [tv_blur] (but never mind)
I do see the point, that a 1-stage filter needs less CPU-power than a 2-stage filter. But imo, this should rather lead to a general object (like [tv_filter]; i can't think clearly right now, but [tv] indicating that it works in time-domain and "filter", should make clear what is meant; maybe [tv_iir] would be better), that can do all lengths of recursive filterings (and is loop-unrolled for low orders) and can have clipping turned on/off (or not)
And I would like to have more control over the filter-paramters: i prefer "y(t)=a*x(t)+b*y(t-1)" to "y(t)=a*x(t)+(1-a)*y(t-1)", especially, when clipping is involved.
Ah, that leads to what i wanted to ask/state anyhow: Is it possible to make objects that perform "scientific tasks" (like convolution) rather than "folkloristic FX" (like smoothing) [pix_convolution] is far more powerful than [pix_smooth] could be. And of course, you can build a [pix_smooth]-abstraction with [pix_convolution] Maybe a bit of a thought before doing a "quick hack" could save programming-time in the long term. (ooh, this sounds really like mr. bad-guy. i don't want to insult anybody)
i do think, that pd is a programming language (with a lot of flaws (in terms of a prog-lang), sure) i do think, that Gem should be a language-extension, rather than a set of cool effects. That's why i thought it a good idea, to make this openGL-wrapping stuff (which is surely harder to use than all those ready-made Geos)
any comments ?
mfg.as.dr IOhannes
Hi list, hi chris.
Maybe a stupid question: What is this [pix_blur] for ? Hey, i don't want to be rude (mr. bad guy again....), but there already is a thing like [tv_biquad] that does very similar things (and more)
I think, Gem should follow pd's (vs. other libraries) object-policy: make a minimum orthogonal object-set, that let's you do "everything" you want. This implies, that there shouldn't be 2 objects, that do basically the same thing. basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is a two-stage feedback-filter.
I do see the point, that a 1-stage filter needs less CPU-power than a 2-stage filter.
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
btw. [tv_*] was meant to "work (only) on series of images", while [pix_*] should work on single images as well. thus [pix_blur] should rather be [tv_blur] (but never mind)
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.
And I would like to have more control over the filter-paramters: i prefer "y(t)=a*x(t)+b*y(t-1)" to "y(t)=a*x(t)+(1-a)*y(t-1)", especially, when clipping is involved.
that's a good suggestion. both can be used for [pix_blur] with only a small change to the code.
Ah, that leads to what i wanted to ask/state anyhow: Is it possible to make objects that perform "scientific tasks" (like convolution) rather than "folkloristic FX" (like smoothing) [pix_convolution] is far more powerful than [pix_smooth] could be. And of course, you can build a [pix_smooth]-abstraction with [pix_convolution] Maybe a bit of a thought before doing a "quick hack" could save programming-time in the long term. (ooh, this sounds really like mr. bad-guy. i don't want to insult anybody)
i do think, that pd is a programming language (with a lot of flaws (in terms of a prog-lang), sure) i do think, that Gem should be a language-extension, rather than a set of cool effects. That's why i thought it a good idea, to make this openGL-wrapping stuff (which is surely harder to use than all those ready-made Geos)
ok this is a HUGE difference in our approaches. i would never assume that anyone using GEM would know how to program a convolution kernel 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.
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 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.
any comments ?
always...
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.
cgc
mfg.as.dr IOhannes
Zitiere chris clepper cclepper@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
Hi,
I think it is very good that this question popped up.
I am trying to sketch the advantages and disadvantages of the different approaches as I see them:
1) Usability and high level objects:
Pro: - user has a single object that does what he wants, using an intuitive name - can be optimized for speed, because its less general
Cons: - confuses the user by adding yet another object to the list of objects that have to be learned. - not as flexible for experimental uses - code duplication (yet another convolution kernel) - building a consistent set of high level object needs organization
2) Building higher level abstractions:
Pro: - usability, name corresponds to function (same as with dedicated external) - allows for a more consistent hierarchy when patching (e.g. general low level objects are externals, abstractions are more specified objects programmed in pd itself). - code base is kept small --> easier to debug/maintain/optimize
Cons: - loss in performance (how much ?) - building a consistent set of high level object needs organization
I think the key question is really the loss in performance. This said, I think we should make a folder within GEM for GEM abstractions, and based on the performance issue decide if a new object will be an abstraction or a dedicated external.
For the special case of "blur", I would have been happier if the pix_convolve object gets optimized, and pix_blur built as an abstraction.
The tv_ objects problem: It would be great if we could come up with a way in GEM to store images and do recursion, in order to implement these effects directly as a patch. Can this be done without loosing too much performance ? I think yes.
Greetings,
Guenter
- Usability and high level objects:
Pro:
- user has a single object that does what he wants, using an intuitive
name
- can be optimized for speed, because its less general
the first is key because it provides readily accessible and identifiable tools for a large number of people already familiar with other video and image processing applications. the second is, for me, fairly critical. what's the point of having video processing code if it can't run at video speed?
Cons:
- confuses the user by adding yet another object to the list of
objects that have to be learned.
- not as flexible for experimental uses
- code duplication (yet another convolution kernel)
- building a consistent set of high level object needs organization
i will actually argue that it will not be confusing at all. certain people can use the higher level object immediately because they recognize it's function as part of a common tool-set.
i agree with the second and third cons
the last point is something that i feel has to be done to GEM anyway. better docs and a well laid out tutorial will go along way toward this.
- Building higher level abstractions:
Pro:
- usability, name corresponds to function (same as with dedicated
external)
- allows for a more consistent hierarchy when patching (e.g. general low level objects are externals, abstractions are more specified objects programmed in pd itself).
- code base is kept small --> easier to debug/maintain/optimize
those are all good points.
Cons:
- loss in performance (how much ?)
- building a consistent set of high level object needs organization
I think the key question is really the loss in performance. This said, I think we should make a folder within GEM for GEM abstractions, and based on the performance issue decide if a new object will be an abstraction or a dedicated external.
as far as performance goes, the current pix_convolve is extremely slow, and needs lots of improvement. there is a great deal of optimization to be done to different kernels: certain types of edge-detection need only luma values thus saving a considerable amount of computation vs a general convolution function. another example is directional motion-blur which only works on a specified axis.
also, the different color-spaces don't handle convolution in exactly the same way. the optimizations can be even greater when the proper color-space is applied to the desired kernel.
For the special case of "blur", I would have been happier if the pix_convolve object gets optimized, and pix_blur built as an abstraction.
my choice for the name [pix_blur] was not the best, since it actually does a motion blur based on feedback rather than a convolution. perhaps it should be renamed to [pix_motionblur]?
The tv_ objects problem: It would be great if we could come up with a way in GEM to store images and do recursion, in order to implement these effects directly as a patch. Can this be done without loosing too much performance ? I think yes.
you are talking about a buffering system? something like [pix_buffer] with [pix_read/write] or tapin/tapout is on my TODO list. i was thinking of making it very simple, and probably even a single object. the control over where images are read in and out would be entirely user controlled as far as reading and writing to the buffer.
the performance question really concerns the overhead of moving memory around. it's much better to do some sort of operation on the data when it has to be moved (the more ops the better), otherwise the whole processing chain stalls while the data is copied from one location to another. in some cases there is no way to avoid this.
cgc
Greetings,
Guenter
hello all,
I think its good to have less objects that have more functionality, but by the same token that intimidates new users and if we were to go in that direction I think a large number of abstractions, or at least more in depth help files to cover "known" uses of these complex objects. These complex objects would end up with much larger more complex help files, which I think is a good thing.
I do also think redundancy is bad, and that a particular operation should be as abstracted from its data-type as possible. (this whole tv. vs pix. is already confusing me. why not one set of objects for image-manipulation, with the ability to apply as texture... )
my 2 cents
Looking forward to trying to openGL wrapper stuff.
Ben
On Wednesday, February 19, 2003, at 03:07 PM, IOhannes zmoelnig wrote:
Hi list, hi chris.
Maybe a stupid question: What is this [pix_blur] for ? Hey, i don't want to be rude (mr. bad guy again....), but there already is a thing like [tv_biquad] that does very similar things (and more)
I think, Gem should follow pd's (vs. other libraries) object-policy: make a minimum orthogonal object-set, that let's you do "everything" you want. This implies, that there shouldn't be 2 objects, that do basically the same thing. basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is a two-stage feedback-filter.
btw. [tv_*] was meant to "work (only) on series of images", while [pix_*] should work on single images as well. thus [pix_blur] should rather be [tv_blur] (but never mind)
I do see the point, that a 1-stage filter needs less CPU-power than a 2-stage filter. But imo, this should rather lead to a general object (like [tv_filter]; i can't think clearly right now, but [tv] indicating that it works in time-domain and "filter", should make clear what is meant; maybe [tv_iir] would be better), that can do all lengths of recursive filterings (and is loop-unrolled for low orders) and can have clipping turned on/off (or not)
And I would like to have more control over the filter-paramters: i prefer "y(t)=a*x(t)+b*y(t-1)" to "y(t)=a*x(t)+(1-a)*y(t-1)", especially, when clipping is involved.
Ah, that leads to what i wanted to ask/state anyhow: Is it possible to make objects that perform "scientific tasks" (like convolution) rather than "folkloristic FX" (like smoothing) [pix_convolution] is far more powerful than [pix_smooth] could be. And of course, you can build a [pix_smooth]-abstraction with [pix_convolution] Maybe a bit of a thought before doing a "quick hack" could save programming-time in the long term. (ooh, this sounds really like mr. bad-guy. i don't want to insult anybody)
i do think, that pd is a programming language (with a lot of flaws (in terms of a prog-lang), sure) i do think, that Gem should be a language-extension, rather than a set of cool effects. That's why i thought it a good idea, to make this openGL-wrapping stuff (which is surely harder to use than all those ready-made Geos)
any comments ?
mfg.as.dr IOhannes
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Wednesday, February 19, 2003, at 03:07 PM, IOhannes zmoelnig wrote:
Hi list, hi chris.
hi IOHannes,
I think, Gem should follow pd's (vs. other libraries) object-policy: make a minimum orthogonal object-set, that let's you do "everything" you want. This implies, that there shouldn't be 2 objects, that do basically the same thing. basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is a two-stage feedback-filter.
...I sympathize with this, but the branching started early on: for example, why have a [square] AND a [rectangle]? Isn't a square just an equal side rectangle?
btw. [tv_*] was meant to "work (only) on series of images", while [pix_*] should work on single images as well. thus [pix_blur] should rather be [tv_blur] (but never mind)i do think, that pd is a programming language (with a lot of flaws (in terms of a prog-lang), sure)
...hey, I understood the difference (guess not everyone reads src/Gnu/WHATSNEW)...which brings up a point about documentation: wouldn't it be better to have one focused document rather than adding documents hither and thither? your recent readme in the OpenGL folder being an example...now there's the docs in /Gem, the docs in /Gem/docs, docs in /Gem/manual, the readme in /src/openGL, and stuff in src/Gnu...then there's the notes scattered throughout the source, and finally, the cvs commit info...not very good from the "usability" standpoint, but you seem to be quite ambivalent to that.
i do think, that Gem should be a language-extension, rather than a set of cool effects. That's why i thought it a good idea, to make this openGL-wrapping stuff (which is surely harder to use than all those ready-made Geos)
any comments ?
...well, true, pd/GEM is a programming language, and it's much higher level than the language it's written in...therefore it's likely that a pure abstraction of a function will be slower than a coded version (tho I realize that won't always be the case)...
...my view is in both camps: we need streamlined building blocks that can do many things they aren't specifically designed for, but we also need objects or abstractions that allow casual users access; otherwise, users and developers will go elsewhere...
...after recently working on the different vertex manipulation oriented geos, it really struck me that "there's got to be a better way": in other words, it was obvious that we don't need or desire a specific geo object for every possible surface/manipulation...so I'm trying to come up with other strategies that are more generalized, but I'm not there yet!
...to end, I think this is a good thing to keep in mind along with the "usability" issue; personally, I develop for this because it allows me to do other productions, not because I want to make a really "clean" tool...I really don't think that our two approaches are mutually exclusive...
...btw, I'm really enjoying the openGL stuff!
l8r, jamie
Hi all.
I've just had a long discussion with my girl-friend, and she said, that it's hard to discuss with me, since i won't give in. Maybe she is right, and i should re-think.
0. dicussion on the list ~~~~~~~~~~~~~~~~~~~~~~~~ unfortunately i have to do my "alternative service" for 7 more months (in october i'll be free (like in "software") again) that's why i'm not so much online (my internet-connection at home is rather sad), and that's why i'm not able to do following as much as i like: update changes i make to the CVS, get changes others made from the CVS, comment these changes, answer all mails that should be answered. Sorry
1. [pix_*] and [yuv_*] and [tv_*] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ there has been much discussion that turned out (i think. did it?) that [yuv_*] should be incorporated into [pix_*]. Of course the same should be applied to the [tv_*] stuff (there are already [pix_*]-aliases, since [tv_*] was split from it.
2. "dummy-users" vs "power-users" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ i totally agree with chris et al. that "dummy-users" and "power-users" are both idiotic terms. I do think that there are no "dummy-users", but i do think that a lot of programs (and probably OSs) create "dummy-users" because of ignorance, what the users are capable of. btw. has not the term "power-users" been invented by micro$oft ?
3. "high level abstractions" vs. "high level built-ins" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ i think i have mad clear, that i would prefer abstractions to built-ins. guenter has made a good list of pros and cons of both of them. basically, i do think (but might, of course, be very wrong), that it all reduces to 3 points: a) speed! b) flexibility c) is it possible at all, to built a specifique function as an abstraction ?
ad a) of course c-coded functions will always be faster than abstractions because of their very nature. but then, it might well be possible, that the speed-loss isn't that dramatic.
ad b) while c(++) offers the most flexibility in general, i think, that abstractions will provide more flexibility to the pd-programmer. (i chose pd, because i don't want to build my framework from scratch all the time (and when i started to use pd, i wasn't able to built my own framework at all)) abtractions can be made that have all the functionality of built-in's, but they can be seen by users. In my (a lot of my ancestors were/are teachers) opinion, users willing to learn can learn a lot from abstractions, users not willing to learn (now), will feel no difference in the usage.
ad c) obviously i cannot make a [pix_smooth] if there is no possibility to apply a convolution kernel.
Conclusions/Solutions: ======================
0. my online presence ~~~~~~~~~~~~~~~~~~~~~ cannot do much about this. sorry
1. [tv_*] ~~~~~~~~~ i will put all tv-objects back into pix
2. dummy-users vs. power-users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ do not exist. don't let Gem generate some
3. abstractions vs built-ins ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ note: this is not intended to be authoritative but a suggestion: abstractions: use abstractions when it is possible without to much speed-loss, whatever is "too much"... built-ins: keep them as flexible as possible (without too much speed-loss). make them as optimized as possible.
=========================== so i have written down a lot of obvious chunk.
mfg.asd.r IOhannes
On Mon, 24 Feb 2003, IOhannes zmoelnig wrote:
- abstractions vs built-ins
note: this is not intended to be authoritative but a suggestion: abstractions: use abstractions when it is possible without to much speed-loss, whatever is "too much"... built-ins: keep them as flexible as possible (without too much speed-loss). make them as optimized as possible.
Lets make a directory for abstractions. The abstractions solution only works if the abstractions are there.
Then there is a lot of work to doregarding the documentation. Why might ask over at the pd list if there are people interested in working on this.
I think these are very important usability issues too.
Guenter
- dicussion on the list
ok not much can be done there so we'll make the best of it. maybe there are some people who are willing to test compiles and features on each platform that aren't developers? that would help out a lot.
- [pix_*] and [yuv_*] and [tv_*]
there has been much discussion that turned out (i think. did it?) that [yuv_*] should be incorporated into [pix_*]. Of course the same should be applied to the [tv_*] stuff (there are already [pix_*]-aliases, since [tv_*] was split from it.
ok, so everything is a pix_*.
- "dummy-users" vs "power-users"
i totally agree with chris et al. that "dummy-users" and "power-users" are both idiotic terms. I do think that there are no "dummy-users", but i do think that a lot of programs (and probably OSs) create "dummy-users" because of ignorance, what the users are capable of. btw. has not the term "power-users" been invented by micro$oft ?
i agree that we should not second guess GEM users. most of my work now is based on requests from people using it. most of them want as many tools as possible and have them be simple to use. and they have to be fast too!
- "high level abstractions" vs. "high level built-ins"
i think i have mad clear, that i would prefer abstractions to built-ins. guenter has made a good list of pros and cons of both of them. basically, i do think (but might, of course, be very wrong), that it all reduces to 3 points: a) speed! b) flexibility c) is it possible at all, to built a specifique function as an abstraction ? ad a) of course c-coded functions will always be faster than abstractions because of their very nature. but then, it might well be possible, that the speed-loss isn't that dramatic.
right. how about starting with the abstractions and if someone goes and optimizes them into C code then that could be available as well. one of the reasons i would like to have the specific coded convolution objects is they make more sense for yuv rather than a generic kernel. for example, edge detection usually focuses on luma only, so that right there is a pretty big increase in efficiency for yuv (slower for rgb because the luma has to be calculated). i will write an altivec version of pix_convolve at some point to hopefully get it somewhat usable performance wise. as a comparison, i used pix_convolve on a p4/2.5Ghz/winXP the other day and it took 40% cpu to process the homer.avi!! convolution is obviously something that requires a great deal of optimization for use in a real-time environment, so i'm all for doing as much as possible.
ad b) while c(++) offers the most flexibility in general, i think, that abstractions will provide more flexibility to the pd-programmer. (i chose pd, because i don't want to build my framework from scratch all the time (and when i started to use pd, i wasn't able to built my own framework at all)) abtractions can be made that have all the functionality of built-in's, but they can be seen by users. In my (a lot of my ancestors were/are teachers) opinion, users willing to learn can learn a lot from abstractions, users not willing to learn (now), will feel no difference in the usage.
both the abstracted version and the higher level built in objects can exist at the same time. so there could be a patch that illustrates how [pix_convolve] can be used to do all sorts of processes. some people would want to check this patch out and figure out how convolution works, while others might not care at all. it's best to leave this as an option to the user right?
ad c) obviously i cannot make a [pix_smooth] if there is no possibility to apply a convolution kernel.
you do have a point about not being able to make _every possible convolution possibility into it's own object, but that's why [pix_convolve] exists. i think that edge-detection and enhancement, blur, sharpen, embossing, and directional blur might cover the 'basics' of convolution. having the most common convolution processes available will let users know that they can apply these processes. of course some sort of documentation/tutorial needs to facilitate the learning process so people can make the jump from using specialized objects to the more general tools. that's really the subject of another thread though...
cgc
chris clepper wrote:
ad a) of course c-coded functions will always be faster than abstractions because of their very nature. but then, it might well be possible, that the speed-loss isn't that dramatic.
right. how about starting with the abstractions and if someone goes and optimizes them into C code then that could be available as well. one of
good (for my ego ;-)) this would produce a fast growing number of fx ("this can be done with Gem") and a slower growing number of optimized fx ("even at the same time")
the reasons i would like to have the specific coded convolution objects is they make more sense for yuv rather than a generic kernel. for example, edge detection usually focuses on luma only, so that right there is a pretty big increase in efficiency for yuv (slower for rgb
yes, i've seen that you can reduce maths a lot with yuv and a non generic-kernel. (on the other hand: as you say: for most yuv-convolutions only the chroma key is needed. it would be good/fast to have a (not-so-)generic object that does exactly this. and let's call it [yuv_convolution] and hey! here we are again - it is a doom loop
p4/2.5Ghz/winXP the other day and it took 40% cpu to process the homer.avi!! convolution is obviously something that requires a great deal of optimization for use in a real-time environment, so i'm all for doing as much as possible.
yes, true.
both the abstracted version and the higher level built in objects can exist at the same time. so there could be a patch that illustrates how [pix_convolve] can be used to do all sorts of processes. some people would want to check this patch out and figure out how convolution works, while others might not care at all. it's best to leave this as an option to the user right?
yes, i guess so. (sigh ;-))
ad c) obviously i cannot make a [pix_smooth] if there is no possibility to apply a convolution kernel.
you do have a point about not being able to make _every possible convolution possibility into it's own object, but that's why [pix_convolve] exists. i think that edge-detection and enhancement, blur, sharpen, embossing, and directional blur might cover the 'basics' of convolution. having the most common convolution processes available will let users know that they can apply these processes.
maybe that's my ignorance of image-processing: i thought, that some of these really only differ in the convolution-kernel, being not further optimizable (for instance: no or sparse zeros) so these objects would all inherit from [pix_convolve] and only set the convolution-kernel to a (scalable) constant.
and here we go:
of course some sort of documentation/tutorial needs to facilitate the learning process so people can make the jump from using specialized objects to the more general tools.
-
bbogart -
chris clepper -
guenter geiger -
IOhannes zmoelnig -
Me -
zmoelnig＠iem.at