Deep Zoom File Format Overview
Microsoft Silverlight will reach end of support after October 2021. Learn more.
The file format used by Deep Zoom source files is XML based. In your source file you can specify a format for a single large image or for a collection of images. This overview explains how Deep Zoom works with these formats.
You can use a tool to create a Deep Zoom source file (for example, Deep Zoom Composer or Photosynth). This provides a way to see how the Deep Zoom file format works, including how the tiles and tile information are stored on disc.
Deep Zoom image pyramids support only the image files supported by the BitmapImage class.
This topic contains the following sections.
- Single Images
- Sparse Images
- File Format Schema Reference
- Related Topics
Single large images in Deep Zoom are represented by a tiled image pyramid. This allows the Deep Zoom rendering engine to grab only that bit of data that is necessary for a particular view of an image. If an image is being viewed zoomed out very far, then a small thumbnail is all that’s needed to show the image on screen.
However, if the user is zoomed in to a specific area of a large image, then only those tiles needed to show the specific areas are downloaded. This can lead to very large bandwidth savings because often only some aspects of a large image are interesting to the user. The illustration below shows what the image pyramid looks like conceptually. An image is stored as a tiled image pyramid. At each level of the pyramid, the image is scaled down by 4 (a factor of 2 in each dimension). Also, the image is tiled up into 256x256 tiles.
If, for example, you were zoomed in to see only the highlighted middle part of the image, Deep Zoom only loads the highlighted tiles, instead of the entire 1024x1024 image.
Each resolution of the pyramid is called a level. Levels are counted from the 1x1 pixel as level 0. Each level is the size 2(level)x2(level). Each level is stored in a separate folder. All levels are stored in a folder with the same name as the DZI file with the extension removed and "_files" appended to it. For example, the pyramid for test.dzi is stored in test_files. Each level may be broken up into several tiles. The tiles are named as column_row.format, where row is the row number of the tile (starting from 0 at top) and column is the column number of the tile (starting from 0 at left). format is the appropriate extension for the image format used – either JPEG or PNG.
Deep Zoom also supports the concept of sparse images. Sparse images allow a user to create an image that has more resolution in some parts of the image than others.
This is useful if a user wants to create an image with a fractal layout, for example a car ad with more details in the bottom right corner, which a user could zoom in to for more information.
The figure below conceptually shows an image pyramid inside another image pyramid (called a sparse image):
A collection is made up of multiple images. Deep Zoom optimizes working with a collection of images by enabling lower levels of multiple images to share tiles which, reduces network traffic and render hundreds of high-resolution images at once. The collection optimization in Deep Zoom takes advantage of the fact that many times a user will want to display related content and then zoom in on one particular detail. With collections, thumbnails of images are stored on a shared tile (of 256x256 pixels).
For example, Deep Zoom can load and decode only one tile, and retrieve the thumbnails for a hundred images in one operation.
The following illustration shows how thumbnails are stored at various levels of detail.
Toward the top of the pyramid, all the images are packed into a single tile. In the middle of the pyramid, images share tiles, but multiple tiles may be needed to contain all the images. At the bottom of the pyramid, there is usually one image per tile.
The Deep Zoom collection is stored in image pyramids much like single images are, including how the tiles are named and numbered. Level numbers for collections refer to the size of each image in the tiles, not the total size of all the images. For instance, at level 2, there is a 4x4 pixel version of each image.
Images are stored in shared levels to make access to related images (which frequently share tiles) much faster and require fewer server roundtrips and less image decoding. Imagine a scenario where all the images on screen are fairly small – it will only require downloading a small number of tiles to get the images required for display.
Note that the items in a collection are stored and laid out spatially in a fashion that scales down nicely from one level to the next. Deep Zoom collections store layout information for individual items in a collection only once for each item. The layout used is called "Morton Layout." The nth item is stored in a location found by separating out the even and odd bits of n, then using those to find a row and column. For instance, the 5th image is 510=1012 which is split into 112=310 and 02=010. So it is stored in the 0th row and 3rd column of the collection.
For example, when building a collection, items are laid out (in chronological order) as follows:
0 1 4 5 16 17
2 3 6 7 18 19
8 9 12 13 ...
10 11 14 15
You can see how this is really a fractal layout and can grow to infinity.
Note that the preceding picture shows only three levels of tiles. However, a collection contains level 0 up to the maximum level chosen for the collection. The tile size must be greater than or equal to 2maxlevel.
File Format Schema Reference
There is a schema specifying the XML structure of the source file used for single images and collections. The following resources are available: