[GEM-dev] Re: [GEM-cvs] Gem/src/Pixes FreeFrame.h, NONE,

[IOhannes m zmoelnig]

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