Hi Joe,
Thanks for explaining.  I think I see what you're getting at.  Assuming that the image blocks were individually compressed or that random access to a given location within a block was slow (for some other reason), one could realize great benefit from caching entire blocks at a time.  For the case of uncompressed NITF files, block boundaries have always seemed random and insignificant to me.  That is, I wouldn't see much advantage to aligning anything along block boundaries; you could still cache pixels, but there wouldn't seem to be much advantage to doing so along block boundaries.  At any rate, I think I see where you're going with this now.  I suppose I'd vote for your first suggestion: move the blocking API directly onto vil_image_resource.

From: Joseph L Mundy [mailto:mundy@lems.brown.edu]
Sent: Monday, December 19, 2005 9:09 AM
To: 'Rob Radtke'; vxl-maintainers@lists.sourceforge.net
Subject: RE: [Vxl-maintainers] Blocked Images?


The need for knowledge of blocking comes up in at least two contexts:

1)    Processing large images, e.g. filtering kernels that span block boundaries.

2)    Displaying large images

Both of these applications will benefit from a smart block cache. The cache anticipates what blocks need to be retained since they are likely to be reused.

If we want to build generic mechanisms that work for both blocked and unblocked images, wouldn’t it be difficult to tell which formats are blocked without methods on vil_image_resource/view?  Also there is no guarantee that the method signatures would be consistent from one blocked image file type to another.


I have no objection to adding the multiple image/file support to vil_image_resource. 



-----Original Message-----
From: vxl-maintainers-admin@lists.sourceforge.net [mailto:vxl-maintainers-admin@lists.sourceforge.net] On Behalf Of Rob Radtke
Sent: Monday, December 19, 2005 10:29 AM
To: 'Joseph L Mundy'; vxl-maintainers@lists.sourceforge.net
Subject: RE: [Vxl-maintainers] Blocked Images?


My thoughts are that handling image blocking is a file read implementation detail that is specific to certain file types.  If a filetype supports blocking then the subclass that reads that type could/should handle it transparently (note that the block related NITF functions below are all protected).  I can't envision a scenario where client code would want to read just the (i,j)-th block or even really a scenario where the client code would need to know the blocking details of a particular file.  Well, I guess the latter case is reasonable just in terms of providing file meta-data.  In the NITF case, one could access this information in one of two ways:


- Use the vil_nitf2 specific get_tree() function which would provide them with all of the support data relevant to either the whole file, or a specific header.

- Use vil_image_resource::get_property() function with the appropriate tags from the NITF specification ("NPPBH", "NPPBV", "NBPR", "NBPC" respectively). 


Assuming I'm not missing something about how TIFF files use blocking, I don't see the need for either solution: moving the blocking API up to vil_image_resource or making a block-aware subclass. 


However, while we're on the topic of moving functionality up to vil_image_resource, I have another question.  Does anyone object to my moving these functions up to vil_image_resource (from vil_nitf2_image)?


  void set_current_image( unsigned int index );
  unsigned int nimages() const;


All filetypes that don't support multiple images in a single file won't be affected; nimages() will return 1 and they will only be allowed to pass one into set_current_image().   As far as I know, vil_nitf2_image is the only subclass for which this functionality will be useful, but this change should make it easier for client code to access this capability. 





From: vxl-maintainers-admin@lists.sourceforge.net [mailto:vxl-maintainers-admin@lists.sourceforge.net] On Behalf Of Joseph L Mundy
Sent: Monday, December 19, 2005 6:33 AM
To: vxl-maintainers@lists.sourceforge.net
Subject: [Vxl-maintainers] Blocked Images?

Dear All,

The vil image library does not currently recognize blocked images. For example TIFF6.0 extends the concept of  “strips” to allow general rectangular “tiles”.  The NITF2.0 and 2.1 file formats also provides blocking.  Indeed, the vil_nitf2_image class has the following methods:

  unsigned int get_pixels_per_block_x() const;

  unsigned int get_pixels_per_block_y() const;

  unsigned int get_num_blocks_x() const;

  unsigned int get_num_blocks_y() const;


I plan to extend vil_tiff  to handle blocks as well. Should we have block parameters and methods on vil_image_resource/view or should there be a sub-class of these that supports blocking?  Also the get_... should be removed in the new block method names according to our vxl coding standards.



Professor of Engineering(Research)

Room 351

Barus and Holley

184 Hope Street

Providence, RI