CZI: questions about openslide grids

[Benjamin Gilbert]

On 12/15/2014 11:08 AM, SOUEDET Nicolas 215310 wrote:
> In CZI format, it is possible to have different tile dimensions for a
> single pyramid level.
>
> That allows to manage scanned ROI accurately, but I do not know how to
> manage it using an existing openslide grid.
>
> Moreover, openslide is built around this prerequisite that tiles of a
> same pyramid level have the same dimensions.

Hi Nicolas,

The OpenSlide core doesn't require tiles to be a consistent size.  The 
tile_w and tile_h members of struct _openslide_level are only used to 
provide performance hints to the application, and can be set to zero if 
they do not apply.

As to grids: the simple grid will not work for you, but the tilemap grid 
might.  It doesn't require all the tiles to be the same size; you can 
specify the tile sizes as arguments to 
_openslide_grid_tilemap_add_tile().  What tilemap does require is that 
each tile can be approximately placed on a grid, such that:

- there is no more than one tile per grid cell, and
- the actual pixel coordinates of a tile are "close to" the ideal pixel 
coordinates of its grid cell.

Depending on how CZI lays out tiles, this may or may not be sufficient 
for you.

- If smaller tiles are only used when the corresponding large tile has a 
single region of interest, the small tile can simply be placed into the 
grid cell where the large tile would go.

- If large tiles are broken into a consistent number of pieces (perhaps 
2 or 4 to a side), which may not all be present, then the tilemap grid 
should be configured with tile advances matching the size of a small 
tile.  When large tiles exist, they will span multiple grid cells, but 
the tilemap grid can handle that.

- If it is impossible to overlay any regular grid on the tiles because 
there is *no* consistent structure, the tilemap grid will not work.  We 
would need to add a new grid that looks up tiles by performing a range 
search over the tile coordinates.  I've previously suggested that that 
could be implemented as a wrapper around the SQLite R*Tree module.

--Benjamin Gilbert