Pages

Sunday 4 September 2011

jpeg vs geotiff speed

A really common question is with respect to jpeg performance being slow.

JPEG is a compression format based on how the human eye works; the eye is very good at seeing a color on one side of a "sky" and another color on the other side of the sky and filling in a nice smooth gradient in your mind. Even when the actual data shown on the monitor does not actually have a smooth gradient.

The jpeg standard uses other silly human tricks about how the eye works in order to throw out information that is not needed because your mind will fill in the gaps giving you the same experience.

To do this it needs the *entire* image; and it also needs the entire image show to your eye.

So it is really not very suitable for GIS use where we expect the image to reflect measurements.

Formats like geotiff and ecw are organised to be read off disk; so depending on where in the image you are they can calculate what area of the file to read; and thus display part of the image without having to read the whole thing.

Even when zoomed out; because the file structure is organised the readers can sample the pixels to pull out just enough information for what is on screen and no more.

For GeoTiff they can even go beyond this and have an overlay of the file which we can display when JMapPane is zoomed out, or internally structure the file with "tiles" for even better performance (less disk seeking) when zoomed in.


There is some good background information on these kinds of topics  from the LISAsoft 2009 making maps fast workshop:
- http://download.osgeo.org/osgeo/foss4g/2009/SPREP/0Tue/Parkside%20GO2/0900/

1 comment:

Paul Ramsey said...

Actually! There is such a thing as an interlaced JPEG, so it can progressively display (but it's rarely used). But more importantly, TIFF is a very generic container, and allows different compression schemes within its blocks, so it is possible to create "tiled TIFF with internal JPEG compression" in which the TIFF is the envelope, containing smaller (256x256 for example) block of data compressed using JPEG. This combo is super for providing both: good overall compression (10:1 or so) and; fast access, since JPEG decompresses faster than JP2K, SID, ECW.

See http://www.gdal.org/frmt_gtiff.html, the TILED=YES and COMPRESS=JPEG and PHOTOMETRIC=YCBCR options.