After considering your ideas I decided that the notion of a blocked_image wrapper is the way to go.
>How about making vil_image_pyramid_resource a concrete derivative of
>vil_image_resource, like one of the algorithm resources (e.g. vil_transpose)
Here is a portion of the interface I am implementing,
class vil_blocked_image_resource : public vil_image_resource
vil_blocked_image_resource(vil_image_resource_sptr const& src,
const unsigned sbi = 0, const unsigned sbj=0);
inline unsigned size_block_i() const
inline unsigned size_block_j() const
I think it works out very well and any image resource can “pose” as a blocked resource. You might say that if the resource, src, is not naturally blocked then the posing would be incredibly inefficient. However, the caching of blocks will make any image an efficient blocked form for most operations. Actually there is nothing new under the sun. There was a similar concept in the ancient TargetJr image library: BlockedFileImage.
The remaining issue is the best way to deal with multiple-image file resources. Right now I am inclined to have a multi_image_resource subclass of image_resource. Then the pyramid image class can be a sub-class of that or maybe better, a direct pyramid wrapper subclass of image_resource, similar to the blocked_image idea. Again, any image can “pose” as a pyramid.
Professor of Engineering(Research)
Barus and Holley
184 Hope Street