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