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.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Rob Radtke
Sent: Monday, December 19, 2005 10:29 AM
To: 'Joseph L Mundy'; email@example.com
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)?
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: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Joseph L Mundy
Sent: Monday, December 19, 2005 6:33 AM
Subject: [Vxl-maintainers] Blocked Images?
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)
Barus and Holley
184 Hope Street