james tittle wrote:

On Apr 20, 2005, at 1:31 PM, IOhannes m zmölnig wrote:

...hmmm...I'm kinda torn on this: on the one hand, it's always nice to

i understand.

extend the capabilities...on the other hand, I don't see how we'll make

...

yuv pathways available, much less the variable number of parameters...

the 2nd one was rather easy: the plugin of [pix_freeframe] cannot be changed once it is created; so the number of parameters stays constant, once the object is initialized;

so [pix_freeframe kaleidoscopeVFX] is really a "long form" for [pix_kaleidoscope] (i mean: it is as static an object)

...in case ya didn't know, the "pete's plugins" that I ported awhile back were originally freeframe plugins, but now they have been adapted

i guessed so when i saw the original code.

to the pix_* system, and therefore have the ability to process rgba and yuv, plus they have help files...of course it's been awhile since I"ve kept up with the freeframe spec, so maybe things have changed (or maybe

well (not too well): it didn't

they should add yuv processing?)...

it's on their feature request tracker; but it seems like the whole project (from the API-definition side) is somewhat dead...

but why not revive it ?

...also, most of the currently released freeframe plugins are not open-source, nor are they made available for non-x86 platforms (I don't even know if the commercial ones will work on linux)...

yes, i even had the same problems when trying to compile the free ones (PetesPlugins) on x86_64;

as with open-source, i haven't looked deeper into that; but then i guess, people are using proprietary codecs too...

...so, I guess you can say I'm heavily skeptical of this, and cautiously indifferent!

i totally undestand it, but:

1) my primary point is not to double coding efforts: i like the idea of heaving 1 standard api for people to develop fx on, and others being able to use it with whatever software (and yes, i agree with matju's mail on that topic (2 years ago) that the API is totally crap. using ioctl...

2) my secondary point is not to waste too much energy in that kind of effects: photoshops "oil-painting" effect sure looks nice, but the second time you see it (and the first time you see it, when you try out some plugins on your personal/pirated copy of photoshop/gimp/whatever) it gets boring; i think nothing is more embarrassing than video artists where you can tell exactly which photoshop plugin they have used to do their (entire) work. there are a lot of video-effects that tend to produce things like that. and if someone would start to port the "oil-painting" effect (or worse: to re-invent it) to Gem/pix just because they need it (i mean: if the whole thing is just for fun, i will not reject), then i am really sorry for that waste of time; they would do better lying around in the grass and counting ants, now that the spring is coming (btw. i can lie down in my kitchen and watch the ants;-))

as for performance, you are surely right: currently it is a cpu-killer (well, it depends: on my 800MHz P3 running one (in my opinion: rather performant) effect on a quicktime-movie took me about 20% cpu-load; turning the effect off (this is: only decoding the video and displaying it) took me about 10%; (but the test machine is really an "office machine": i constantly have 3MB of free ram!)

so, i appreciate the work you have undergone when porting some of PetesPlugins: besides from adding some cool effects, they showed me that there was an obvious need for such effects; but why waste too much time with them ? (PetesPlugins are not entirely easy to port...)

mfg.a.sdr IOhannes