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

    {return sbi_;}

  inline unsigned size_block_j() const

    {return sbj_;}



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)

Room 351

Barus and Holley

184 Hope Street

Providence, RI