[PD-dev] [GEM] names
chris clepper
cclepper at artic.edu
Wed Apr 30 02:31:39 CEST 2003
>All the new names sound good to me, but I wanted to clarify
>pix_background a bit:
>
>Does it just subtract a reference frame (background) from the
>current frame and then apply that as an alpha channel to the
>outgoing frame? (or does it fill the background with a color?)
There is no alpha involved at all, the 'static' pixels are turned
black and you can key those out using pix_chroma_key if you want.
the idea was to have the background removed and use the remaining
pixels to do your own effectv type thing. i was planning on doing an
inverse function that kept the background and set the movement pixels
to a color.
>perhaps something like pix_key makes the most sense, may be used for
>a background, but maybe not, but as some other keying type. pix_key
>could do the above mentioned operation on a the current frame coming
>into the left inlet using the "key" (background etc.) coming into
>the right inlet?
hmm that's possible but there's already a pix_chroma_key which
actually does what the name says it does. there are some yuv_
objects called isolate and replace that do similar things but don't
compare to a reference frame. maybe all of this could be rolled into
a more generic object that removes or otherwise processes 'moving'
pixels vs 'static' ones. pix_key is a bit generic, how about:
pix_static? pix_remove? pix_remove_static_pixels?
>Some ideas anyhow,
>
>Will get cracking on some tutorials once my move is over!
great. let me know what you are writing so we can coordinate.
>Oh and one other suggestion, on my last project it was quite anoying
>to have the video render stop when a new set of still jpegs were
>loaded into pix_images. Would it be possible to thread the
>image-loader so that it does not interupt video rendering? (same
>goes for video files, but I think those loaders are already
>threaded?)
the first step might be to try just opening the file in a separate
thread and see if that helps, the disk I/O might be the snag for a
jpeg. but i think to be really effective it requires the image to
be loaded and decompressed into a buffer in the load thread and then
mecpy into the render thread. so the stall while loading an new
image would be replaced with a slowdown while the file is grabbed and
decompressed then copied. of course on a dual-cpu box this could be
quite a performance boost.
cgc
>Ben
More information about the Pd-dev
mailing list