Hi,
My application displays very large images at different zoom factors. I have
tiled my images into individual tiles of a much smaller size. Each image has
hundreds of tiles. The tiles will be used to interactively display the image
and the speed of the zooming and panning is very important.
That's why I am thinking storing the tiles into an SQLite database. I am
soliciting some advice on how to setup the index.
The main column for a Tile table will be its pixel blob. I can setup the rest
of its structure as I wish. For example:
left: integer horizontal offset of the tile
top: integer vertical pixel offset of the tile
width: integer horizontal size of the tile
height: integer vertical size of the tile
shrink ratio: a power of two. How much the resolution of the tile has been
reduced from the image resolution
width and height are typically constant, equal, and a power of two. The
exception is at the right and bottom edges for the right-most and bottom-most
rows of tiles for images that have non-power of 2 dimensions.
In memory, my data structure is a quad tree. The leaves of the quad tree point
to elementary tiles: tiles that holds exact pixels from the image at the same
resolution. At he next tree level, I take 4 tiles (arranged in a square) and
make a new tile from them. This new tile is shrunk in resolution from its 4
source tiles by a factor of 2 in each direction. That is, each of its pixels
represent 4 pixels from the source tiles. I iterate at the next level.
Conceptually, this process stops when level n has only one tile, which can be
considered as a thumbnail of the original image.
When I need a tile, I know the topleft of the tile and I know the current zoom
factor. The zoom factor can be 1.0 (actual pixels) or smaller (zooming out).
From the zoom factor, I can easily compute the shrink ratio to use: I want to
use those tiles that have just enough resolution, not better, as that would be
wasteful and I am memory constrained (I can't load the full image in memory at
any time). To find out the shrink ratio, it's basically 1/zoom factor, rounded
to the correct adjacent power of two.
The set of tiles needed at any given time is those that cover (at least
partially) the displayed rectangle. The number of needed tiles is constant for
a given window size, since tiles have a constant size (not quite constant: edge
and zoom rounding effects can affect slightly that number. at least there is a
known upper bound to that number). That number is small, much smaller than the
number of elementary tiles. The required tiles are adjacent: they form a
connected rectangle.
Note that I can set up my Tile table differently if I want. For example, I can
use row and column numbers rather than left and top since the pixel sizes are
known.
My question is: is there any smart way to set up my table index? My naive idea
is to have a composite index: shrink ratio/left/top (or ratio/row/column).
Is there any better? For example is there any reason to prefer either of
ratio/left/top and ratio/top/left?
Is there any reason to consider smart encodings similar to geo hashing where
each additional bit in an identifier encodes a smaller area?
I realize that since I have only hundreds - not millions - of tiles, this may
sound like premature optimization. But I am not after optimization here (yet),
only after sensible design.
Thanks,
Jean-Denis
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
