Dev:Source/Sequencer/Image Buffer

Image Buffer

The Image Buffer needs to be a place for Blender to store Image/Video information that it is working on (rendering/mixing). There should be functions to act on the image buffer such as save/load, convert internal storage formats (float/16/32 bit). By allowing different storage formats, High Resolution Color file formats could be supported (open EXR).

An Image buffer should manage it's own size automagically. If a change in format (bit depth/planes) or length, then it should re-allocate memory, do the conversion, and release any unused memory using Blender memory management functions. Endien issues should be taken care of by global functions/macros and not included in this API. Platform specific codec functions should be addressed in this API for taking advantage an OS provided codec.

Proposed Image Buffer Class/Structure:

• buffer-> Allocation of memoryx_sizey_sizebpp*frames
• temp_buffer->location to allocate new memory for conversions, swapped with buffer when complete and then freed
• format->flag for bpp, planes, and type (float/int)
• x_size->int
• y_size->int
• frames->int
• current_frame->points into buffer to beginning of current frame. On static images, points to begining (i.e. buffer)
• fps->float
• aspect_ration->float
• animation->bool
• frame_size->int, size of frame in bytes

proposed functions to work on an image buffer object

• Allocate new image buffer
• Save image buffer to disk (filename, format)-still or movie
• load image buffer (filename)
• convert image buffer (format)
• display image buffer (still, movie)
• get frame (frame)-single frame

Audio Buffers???

May want to have an audio buffer object. These would be very similar to image buffers in data storage, and functions to work on them. May want to derive from a common base class (abstract?). These can then be used in the game engine as well for a unified front end, then the Open AL/SDL decision could be seperated out. This would allow the user or OS to determine what sound system to use.

-- RobertHolcomb - 20 Jan 2005