Let’s say you’ve got a lot of raster files you want to host on your map server, or even just one large backdrop. I needed to do the latter, but either way, you’re faced with the same problem: how can I reduce file size and access time? Whatever else I do – such as building pyramids – my raster file is going to be compressed some way or another. I can’t very well have visitors waiting for my server to run through an elaborate (de)compression method, but neither can I store images of the whole of South Africa and the world at several GB per file without perhaps running out of space.
Depending on the amount of space I have on the server, I might be prepared to sacrifice some speed to save space, or vice versa. So what’s the best compression method for my requirements?
I used GDAL’s translate utility (more info here) and went through several of its options to get a better idea of what’s on offer. For compression, my bash command basically looked like this:
gdal_translate <compression options> -of GTiff input.tif output.tif
To test response times, I ran these commands to export the compressed file to thumbnails of various sizes:
time gdal_translate -outsize 80 60 -of GTiff output.tif thumb-output.tif time gdal_translate -outsize 800 600 -of GTiff output.tif thumb-output.tif time gdal_translate -outsize 1280 1024 -of GTiff output.tif thumb-output.tif
(In retrospect, it may have been better to remove the thumbnail between each step rather than overwriting it, to better replicate conditions. Still, I don’t think it made much of a difference.)
My results are summarized in the graphs below, using the following labeling scheme:
Name: Compression options N/A : -co COMPRESS=NONE A : -co COMPRESS=LZW -co PREDICTOR=1 B : -co COMPRESS=LZW -co PREDICTOR=2 C : -co COMPRESS=PACKBITS D : -co COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=1 E : -co COMPRESS=DEFLATE -co PREDICTOR=2 -co ZLEVEL=1 F : -co COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=6 G : -co COMPRESS=DEFLATE -co PREDICTOR=2 -co ZLEVEL=6 H : -co COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=9 I : -co COMPRESS=DEFLATE -co PREDICTOR=2 -co ZLEVEL=9
Going by these results, you can choose whichever compression best suits your requirements. For the shortest access times, you could use “packbits”; however, this also gave the largest (compressed) file size. For the smallest files size, “deflate” with a predictor of 2 and zlevel of 9. For a compromise, you could consider “deflate” with a predictor of 1 and zlevel of either 6 or 9.
Obviously, there are more permutations of this; you could include pyramids as well (use gdaladdo), for example. Or you may be willing to consider JPEG compression if you don’t mind the quality. In any case, I hope this article gives you ideas on where to look!
![aa_graphSpace Fig. 1 [image]](http://linfiniti.com/wp-content/uploads/2011/05/aa_graphSpace.png)
![aa_graphTime Fig. 2 [image]](http://linfiniti.com/wp-content/uploads/2011/05/aa_graphTime.png)
trk
The “predictor” options go back to the TIFF standard. Consider the difference b/w compression needs across one byte (i.e. eight bits), two bytes, etc. Say what?
A quick example? OK. The high and low order bytes in a 16-bit dataset will clearly have different characteristics. Ah .. believe this (16-bit data) to be a case for “Predictor=2″ . There is a post on a GDAL forum pointing out how this works for ASTER GDEM V001 (why horizontal differencing matters and the change in storage requirements).
If there is a follow-up comment, there may be found sufficient motivation to point to the right places in the right docs. No promises
Rudi Thiede
@trk: Interesting, thanks!