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

[chris clepper]

>0. 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.

>
>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.

ok, so everything is a pix_*.

>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 ?

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!

>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.

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