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?)
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?
Some ideas anyhow,
Will get cracking on some tutorials once my move is over!
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?)
Ben
----- Original Message ----- From: chris clepper cclepper@artic.edu Date: Monday, April 28, 2003 7:00 pm Subject: [PD-dev] [GEM] names
Hi
I mentioned in the last post about a new GEM release that some of the names of various objects don't really match what they do very well. i think i've said on a few occasions that the name of the object needs to tell the user what they do rather than be some excessively cute, clever name from a book no one has read, Hindu deities or someone's cat (btw, all of these are used as names in other video systems). so here's a list of objects and suggested changes:
- pix_blur - this should be renamed pix_motionblur and pix_blur
will be an abstraction for a convolution based blur.
- pix_buf - would it be better to rename this pix_separator to
mirror the separator object? pix_buf can remain for compatibility.
- pix_depot - why not call it pix_buffer? or pix_table or
pix_array? something that is a common term for a chunk of memory filled with data (frames of video in this case). yes, a depot is a place to store things but it's mainly used as a military term or in the name of a large chain of hardware and office supply stores in the US (Home Depot and Office Depot respectively).
- pix_put/get - could be pix_buffer_write and pix_buffer_read.
these seem a little more specific to me and the name-space extension allows for direct association of functions with the pix_buffer object.
also i was thinking of making objects that performed various actions on the buffer or used it in some way for processing. also, this could facilitate non-realtime renders. examples:
pix_buffer_average - averages the frames in the buffer and stores the result as a single frame. useful for motion detection and compositing and pix_background type effects
pix_buffer_record - dumps the contents of the buffer into a Quicktime .mov and compresses them. could be useful in situations where the frames can be stored in the buffer but compression takes too much time to be done in real-time (like MPEG-2 or 4).
pix_buffer_motionblur - really high quality motion blurring requires lots of frames to be used and is generally not a real-time operation. if you've ever seen the shake motion blur you know about this.
there are some other ones that are new to CVS that might need better names:
- pix_background - this removes the background from based on a
static image snapshot. is there a more meaningful name that better describes this? pix_background_remove is a bit excessive i think.
- pix_scanline - this does image decimation based on either
repeating or removing rows of pixels, so it does do scanline processing but is that really clear?
i don't think any of the objects are really in wide-spread use except for pix_buf which can remain for compatibility purposes. maybe this is just a personal pet-peeve, and no one really cares what the objects are called as long as they work, but i thought i would make some suggestions and see what people think.
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
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
-
bbogart＠ryerson.ca -
chris clepper