Request for features

I have always tried to make VLIV as simple as possible, while keeping it as powerful as possible.
So the number of features is quite limited, compared with other Viewers such as IrfanView.

I would like to keep the initial idea, that is focusing on Very Large Images, but like to know what you, users have found missing in VLIV.

I have some ideas myself, but time is missing for large improvements.

So please do not hesitate to ask for features in this article comments, I will consider all propositions.

Printing size of very large images

Imagine we have a Very Large Image (such as the one generated from NASA Blue Marble NG).
The dimensions in pixels are 86400 x 43200 (remember it's the Earth at 500 m/pixel).

My screen (20 inches 16/10 DELL 2005 FPW) dimensions are about 44 cm x 27 cm (17 x 10.6 inches) for 1680 x 1050 pixels.
Simple math gives us 86400 / 1680 = 52 and 43200 / 1050 = 41.
This means that in order to view the complete image, we would need a matrix of 52 x 41 = 2132 monitors !!

Now lets' go to printing. Maximal resolution the eye can distinguish is about 254 DPI (100 pixels / cm). Now this means that the printed size of the image is : 86400 / 100 = 864 cm and
43200 / 100 = 432 cm (340 x 170 inches). This is huge, it would require more than 640 A4 sheets of paper !!


I have a poster printed from the NASA image. It's about 122 x 76 cm and has been printed at 254 DPI. While it's already very nice, it's only 1/8 of the possible printed size at full resolution.
Here is a small version :

VLIV, The Very Large Image Viewer for Windows

In my spare time, I have coded VLIV as an exercise in programming Windows.
The idea was to create a minimal viewer for very large TIFF (tiled).

It uses a very simple idea : only visible tiles are loaded in memory, as soon as a tile is no more visible, it is discarded.

This works very well, because in no more than the visible tiles have to be loaded, so that panning is fast, and zooming also.

VLIV has no advanced features you could think of, such as a caching, or loading tiles in advance, mostly because on local files, performance is already very good.

TIFF has built in support for tiles, but VLIV also creates Virtual Tiles for some formats that have no native tile support (such as PPM or BMP). It manages only parts of the images instead of loading completely the image, even if the format does not support natively tiling.

It also uses a special capability of the JPEG format to allow instant unzooming.

Here is a screendump of VLIV in action on a 86400x43200 pixels image:



VLIV is Shareware, and the price is 10$ (or Euros). I give instructions on VLIV site to build the shown image.

Image formats capabilities

While most image formats are able to store very large images, not all formats are suitable for displaying these images.

The most important capability is a way to directly access a small subsection of the complete image. This is generally achieved by tiling, but some formats allow arbitrary access, so that the tiling feature can be implemented.

Another capability is a way of storing multiple sub-resolutions, thus allowing zooming. Some formats have this built-in, others give a way to compute sub-resolutions using special capability of the format.

The last capability is support for very large file sizes, because Very Large Images require large file size.


Here is a sum-up of these capabilities:

TIFF 32 bit file size limit and consequences

The existing TIFF format is limited in size to 4 gigabytes (because of 32 bit offsets). This format allows data to be compressed using various methods, the most used are deflate (Zip), JPEG and Packbits.

Deflate and Packbits are so-called lossless compression, while JPEG achieves high compression ratios using a lossy method.

Deflate compression rates are about 4:1 on typical photographic images, while JPEG is more in the 10:1 using minimal loss of perceptual quality.

The following table shows what dimensions can be achieved with different compression ratios:

There is an ongoing project called BigTIFF that will break these limitations by a large amount, as it is expected to use 64 bit sizes.

Very Large Images on your disk

While there are quite many images you can view on the Web (see previous post), there are actually very few you can download to your machine.

You can find few on my VLIV viewer page, and instructions to create the NASA Blue Marble Next Generation from NASA dataset

As most technologies to provide Web viewing are HTTP based, it is quite easy to use a mass downloader to download individual tiles just like the Web viewing techonogy does. Rejoining them to recreate the full image is easy then. Because of copyrights and intellectual property, I will not disclose how to do, but so far I have successfully recreated images originating from the Google Maps API (easy) and Zoomify (harder), even multiple Gigapixel ones.

The most common format for tiles is JPEG, and the largest image I have is about 360x350 tiles of 256x256 pixels.

Needless to say, viewing very large images stored on a local disk is impressive, because of the speed compared to Web viewing. There is no delay when panning and zooming.

Large images on the Web

Giving a public access to gigapixel images requires that you have a way to make them accessible through the web.

There are quite a few technologies that allow this, here are the ones I know about:

1. The Google Maps API, written in Javascript + DHTML
2. Google Earth, a standalone application using HTTP to retrieve tiles.
3. Zoomify, written in Flash
4. FSI viewer, also written in Flash I think.

With these technologies, a few very large images can be viewed on your browser:

1. The Earth, on Google Maps, using a mix of satellite images and maps
   
2. The Blue Marble Next Generation Dataset from NASA on Yawah (resolution is 500 meters/pixel, so the complete image is about 86400x43200 pixels)
3. Digital photography, such as
• xRez (stitching a large array of digital images)
• The Gigapxl Project (scanning a very large format argentic film)
  
• Hal9000 Ikonos (stitching a large array of digital images)
  
• Scott Howard (Machu Picchu and Sydney By Night) (stitching a large array of digital images)

Other sites provide information on very large images, but do not make them available to the public:

• Max Lyons (who was the first to break the Gigapixel barrier for stitched digital images)
  

If you know other sites providing very large images, please comment.

Pyramidal tiling data organization

So we do not want to load the complete gigapixel image in memory. What can we do about it ?

The first idea is to use a scheme that is called tiling. The image is internally organized as an array of rows and columns. This organization makes possible to retrieve a part of the image without loading the complete image. Requesting a part of the image is now requesting only the tiles that are intersecting this part.

Imagine you have a 10000x10000 pixels images, divided in 256x256 pixels tiles. If you want to display only the top-left part on your 1280x1024 screen, then you only need to load 5x4 = 20 tiles, that is 196 608 bytes x 20 = 3 932 160 bytes, instead of 300 000 000 bytes to load the entire image.

This has three immediate consequences :

1. Image loading is very fast, because you only load what is visible on the screen
2. Image panning can also be made very fast, because as you pan around, tiles not visible can be discarded from memory and visible ones are loaded (this is called on-demand loading)
3. Memory requirement is almost constant is about the memory needed for one visible screen of data, regardless of image size, so that you can now load your image on any PC, even PCs with as less as 128 megabytes of memory

Now that we are able to freely pan the image, we may want to be able to zoom out, up to the point where the entire image is visible. Tiling will not help here, because in order to display the complete image, we need to access all pixels, that means loading the whole image to compute a reduced version of this image. This is where pyramidal comes in. The idea is to generate images that are reduced version of the complete one, each beeing 2 times smaller than the previous one. (Un)Zooming is now only a matter of switching between these resolution. Of course these subimages are themselves tiles to allow arbitray access.

Let’s take a small example with an original image that is 10000x8000 pixels. We would generate a pyramid of images:

• 10000x8000 (level 0)
• 5000x4000 (level 1)
• 2500x2000 (level 2)
• 1250x1000 (level 3)

We can see that at level 3, the complete image fits into our 1280x1024 screen. If we are at level 3 and want to zoom in, then we switch to level 2, and so on.

We now have an organization of data that allow us to zoom and pan freely in our large image, with memory requirements limited to our physical screen size !

Of course you may say this comes at a cost in storage, because we have to store all these additional levels. What cost exactly ?

If the image size at level 0 is 1 unit, then level 1 is 1/4 this unit (0.25), level 2 is 1/16 and so on.

This is a very well known mathematical suite whose limit is 1.33333333.., so the overhead is not very large given the benefits.

This pyramidal tiling is used in at least two very widely known applications :

1. Google Earth
2. Google Maps

How many people have 4 gigabytes of memory ?

While most computers can display images taken from a digital camera, a special care is required to allow display of gigapixel images. Let’s see why.

Usually, a pixel takes 3 bytes of memory, one for each Red, Green and Blue component. Standard image viewers are loading the image completely in memory to display it, even if visible area of your image is only 1280x1024 pixels because of your physical screen size.

Best digital camera have a 12 Megapixel sensor, let’s say 4000x3000 pixels. This makes 36 000 000 bytes required for storing in memory the image. This is possible on any machine available now.

Let’s now take a gigapixel image at 40000x30000 pixels. This makes 100 times more memory, peaking at 3 600 000 000 bytes, that is 3.6 gigabytes.

Unless you have actually 4 Gigabytes of memory and your OS allows a chunk of this size to be allocated, then there is no way you can display the image on your machine, standard software will either crash or not allow image loading or will take forever to load.

Unless you use some clever way of organizing the image data and you have a dedicated viewer that knows how to handle this specific organization.

Next post will discuss this organization, usually called pyramidal tiling.

Welcome

Hi all,

This blog is dedicated to so called gigapixel images, ie images with dimensions in excess of 30000x30000 pixels.
These image are becoming more and more common. Posts will deal with topics such as tools to build these images, tools to display these images (with emphasis on my own viewer http://vlivviewer.free.fr/vliv.htm),where to get those images, and technical issues when dealing with such large image sizes.