SaladoPlayer:Deep Zoom
From PanoZona
This article attempts to provide explanation on what is Deep Zoom format and how it is used by SaladoPlayer. You can use SaladoConverter to perform operations on images and covert them to format that can be displayed with SaladoPlayer. For more information about Deep Zoom see: openzoom.org or two part detailed analysis by Daniel Gasienica: part 1 and part 2.
Equirectangular panorama is something you may recieve as output from Hugin, it has strict size proportions: width = 2 * height. Equirectangular panorama is texture you could wrap around a sphere. Because texturing and rotating sphere is hard to implement and results in poor performance, in order to display panorama with SaladoPlayer, SaladoConverter transforms equirectangular panoramas into cubic ones. Size of cube wall depends on size of equirectangular image and it can be calculated as: width of equirectangular image / 3.14
Cube walls
Folder name | Cube wall |
---|---|
name_b | back |
name_d | down |
name_f | front |
name_l | left |
name_r | right |
name_u | up |
Folders containing cube walls have to be named specifically in a way that describes their content. Only folders named along such pattern can be recognized by SaladoPlayer as cube walls. If you are feeding SaladoConverter with six cube walls, you need to keep naming convention for image files as well.
Cube wall description file
<?xml version="1.0" encoding="utf-8"?><Image TileSize="256" Overlap="1" Format="jpg" [...]> <Size Width="1024" Height="1024" /></Image>
Attribute | Description |
---|---|
TileSize | Maximum size of single tile. TileSize does not include Overlap value. |
Overlap | If tile is not located on the edge of cube wall, its width and height is incremented with overlap value. |
Format | Image format of all tiles. |
Width, Height | Size of cube wall. |
According to Deep Zoom specifications, every processed image is outputed as number of folders with tiles of different zoom levels, plus *.xml file that describes tiled image. This file is used to recognize original image size, it is also used to predict number of zoom levels and naming of tiles. SaladoPlayer assumes that all cube walls are of the same size, so it only requires data contained in *.xml file describing front cube wall.
Zoom levels
Level | Size | Operation |
---|---|---|
11 | 2048 | - |
10 | 1024 | 2048 / 2 |
9 | 512 | 2048 / 4 |
8 | 256 | 2048 / 8 |
7 | 128 | 2048 / 16 |
6 | 64 | 2048 / 32 |
5 | 32 | 2048 / 64 |
4 | 16 | 2048 / 128 |
3 | 8 | 2048 / 256 |
2 | 4 | 2048 / 512 |
1 | 2 | 2048 / 1024 |
0 | 1 | 2048 / 2048 |
Number of zoom levels is determined only by size of processed image. Starting with size of original image, every next zoom level is half of the size of previous one, and this proceedes down to level of size of single pixel. For example, cube wall of size 2048 px has 12 levels of zoom (0 to 11):
Tile sizes
Level | Size | Relation |
---|---|---|
11 | 2048 | >= 512 |
10 | 1024 | >= 512 |
9 | 512 | >= 512 |
8 | 256 | < 512 |
Every zoom level is individually tiled. Maximum size of every tile is limited, but tiles can be smaller when located on right and/or bottom edge of cube wall or when zoom level is actually smaller then tile size itself. Tile size determines which zoom levels are not used by SaladoPlayer and therefore are obsolete. SaladoPlayer consideres highest zoom level that consists of single tile as lowest one, all lower zoom levels are ignored and can be safely deleted. For instance for cube wall size 2048 px and tile size 512 px:
Performance optimization
Every tile needs to be individually downloaded and transformed along camera movement when panorama is rotated. This means that cube wall that contains fewer number of bigger tiles will be loaded faster and will be displayed more fluently than one with higher number of smaller tiles. However, if tile size is too big, given fragment of panorama takes long time to load. Recommended size of tile is between 400 and 600 px. The least desirable situation occures when multiplication of tile size is slightly lower then cube wall size. In such case edge tiles are very narrow and this results in worse performace: Separate loading operation is performed to display very small fragment of panorama and cube consists of higher than nessesery number of tiles. This problem can be solved by setting tile size to division of cube wall size. In order to achive this effect for all zoom levels, cube size should be divisible by possibly high even number.
Latest version of SaladoConverter automatically adjusts cube and tile size inside given limits. If you think that this feature is not working well enough, you can set cube walls and change tile size manually to achieve different results. Best way to determine which cube and tile size gives best performance for panorama of given size is to try different combinations and measure number of rendered frames on panorama autorotation (see: stats). You can save some time by performing conversion from equirectangular to cubic once, and using cube as input for next conversions.