Matt Leotta wrote:
> I have implemented a vidl_frame_resource to be returned by
> movie->get_resource instead. The frame resource keeps a pointer to
> the movie and frame number. The frame is not decoded until get_view
> is called on the frame resource. The old functionality is still
> available by calling get_view and wrapping the view into a memory
I don't know much about vidl, but this vidl_frame_resource is exactly
the way I intended vil_image_resource to be used - I'm glad someone is
finding it useful.
> Finally, does anyone have any suggestions on modifying the vidl API
> to make it more usable? It seems that it has been ported from Target
> JR and then ported again to use the new vil library. I'm not sure if
> the original API is acceptable anymore. The biggest problem I am
> having is saving movies. The API expects you to have created your
> entire movie object in memory and then save it all at once. It also
> only lets you specify the filename and type where "type" is the vidl
> codec to use (AVI, MPEG, image list). In general there are many more
> parameters that need to be specified and no way to specify them.
> My impression is that most VXL users who work with encoded video
> are not using vidl. It would be nice to have a core video library
> that handles reading and writing without so much trouble. Any
> suggestions other than a redesign from the ground up?
Frank Bettinger (who is no longer at Manchester) wrote a movie library
and published it at contrib/mul/mvl2. There might be some ideas there.
In my experience of writing vil, and other libraries with similar
"properties" problems, I have used several solutions. I suspect that
vil's may be suitable here:
vil_image_resources read from disk can report various properties through
the base class get_property method. However, setting these properties
during image writing, is both trickier and easier:
It is trickier, because having a set_property method in the base class,
can lead to all sorts of error reporting difficulties. However, this
turns out not to be a problem because writing is easier that reading in
one special way. When you are reading an image (or movie) your programs
often do not want to know when the image type is - they just want to be
able to read the image. When writing, however, your program needs to
know explicitly what image type it wants to use. So you can down cast
from the vil_image_resource to the vil_jpeg_image (or what-ever) and set
the relevent property (e.g. set_quality()) on the concrete derived class.