[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 

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.



More information about the Pd-dev mailing list