<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1515" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi Bill,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I am not an expert on this like most
people on the list, but in my experience performance in mapserver is not really
comparable to decompressing an entire image in its entirety. I suppose it
depends on your system, whether harddisk speed is a bottleneck versus CPU.
</FONT><FONT face=Arial size=2>I actually get the best performance on my sites
when I use ECW's (better than TIFF), whether my ECW's are big (2.5GB) or small
(10MB). Probably because my bottleneck is the harddisk speed, not the CPU
(Running a normal pc as server). I notice people running larger sites with many
visitors prefer to reduce the load on the CPU by running fast harddisks with
uncompressed TIFFs. So I guess you need to see whether you expect a lot of
visitors (>100 / hour?). If so, your CPU may not deal well with compressed
imagery, slowing down your site.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Hope this helps...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>regards,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Jacob</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>» -----Original Message-----<BR>» From: <A
href="mailto:gdal-dev-bounces@lists.maptools.org">gdal-dev-bounces@lists.maptools.org</A>
<BR>» [mailto:gdal-dev-bounces@lists.maptools.org] On Behalf Of Bill Binko<BR>»
Sent: 30 August 2005 14:30<BR>» To: GDAL Developer List<BR>» Subject: [Gdal-dev]
Advice on Raster Formats<BR>» <BR>» Hello everyone,<BR>» <BR>» I need some
advice on how to store and process raster images <BR>» I'm working<BR>»
with. The images have generally come in as either ECW (or <BR>» JP2000 --
my<BR>» choice) or MrSID format. They are aerial images (DOQQs generally
at<BR>» 1meter accuracy).<BR>» <BR>» I need to be able to serve these up
efficiently using <BR>» mapserver (through <BR>» GDAL, of course). The
output will be a 24 bit JPEG (with <BR>» overlay data <BR>» unfortunately
compressed as well) that will be sent over the <BR>» wire to the <BR>»
client.<BR>» <BR>» My problem is that both the ECW and the MrSIDs take a very
<BR>» long time to <BR>» decompress, but GeoTIFF takes an ungodly amount of disk
<BR>» space. Here are <BR>» some numbers I just grabbed at random:<BR>»
<BR>» I took the same data in GeoTIFF, ECW, and MrSID formats and <BR>»
decompressed <BR>» them (to MEM which I thought would be a good comparison to
<BR>» reading into <BR>» mapserver).<BR>» <BR>» $ time gdal_translate -of MEM
Q2918se.tiff /dev/null<BR>» Input file size is 6337, 7082<BR>»
0...10...20...30...40...50...60...70...80...90...100 - done.<BR>» 0.72user
0.52system 0:02.79elapsed 44%CPU (0avgtext+0avgdata <BR>» 0maxresident)k
0inputs+0outputs (0major+37327minor)pagefaults 0swaps<BR>» <BR>» $ time
gdal_translate -of MEM Q2918se.sid /dev/null<BR>» Input file size is 6337,
7082<BR>» 0...10...20...30...40...50...60...70...80...90...100 - done.<BR>»
55.80user 7.78system 1:12.57elapsed 87%CPU (0avgtext+0avgdata <BR>»
0maxresident)k 0inputs+0outputs (3major+631879minor)pagefaults 0swaps<BR>» <BR>»
$ time gdal_translate -of MEM Q2918se.ecw /dev/null<BR>» Input file size is
6337, 7082<BR>» 0...10...20...30...40...50...60...70...80...90...100 -
done.<BR>» 25.92user 1.43system 0:29.80elapsed 91%CPU (0avgtext+0avgdata <BR>»
0maxresident)k 0inputs+0outputs (0major+38181minor)pagefaults 0swaps<BR>» <BR>»
As you can see, MrSID is more than twice as slow as ECW, and <BR>» GeoTIFF
just<BR>» flies. The flip side (disk space) can be seen here in a
directory<BR>» listing:<BR>» <BR>» 19226192 Aug 30 02:05
Q2918se.ecw<BR>» 7601858 Aug 30 02:21 Q2918se.sid<BR>» 134983605 Aug
30 02:00 Q2918se.tiff<BR>» <BR>» What I'm considering is keeping the full-scale
files in MrSID <BR>» format, and<BR>» keeping overviews (pyramids) of lower
resolution images in <BR>» ECW. Assuming<BR>» I need four layers (dividing
each side by 2 -- and the area <BR>» by 4) or so<BR>» for adequate performance,
the image above would take:<BR>» <BR>» 7.6 (base) + 19/4MB (layer1) + 19/16MB
(layer2)+ 19/64MB (layer3) + <BR>» 19/256MB (layer4).<BR>» <BR>» That adds up to
13.9MB, a far cry from the 130MB TIFF.<BR>» <BR>» This also gives me the ability
to keep a lossless (MrSID) <BR>» file in case I <BR>» ever want to convert to
GeoTIFFs in the future.<BR>» <BR>» Does this make sense? Are there better
ways to get <BR>» performance out of <BR>» MrSIDs? Should some of the
higher (and smaller) layers stay GeoTIFF?<BR>» <BR>» I'm sure that someone will
say "Hard Drives are Cheap", and I <BR>» agree, but <BR>» it seems that this
data is growing at outrageous rates <BR>» (uncompressed), and <BR>» that the
time spent reading the entire GeoTIFF becomes a bottleneck <BR>» anyway.<BR>»
<BR>» I'd really appreciate any advice,<BR>» <BR>» Thanks<BR>» Bill<BR>» <BR>»
_______________________________________________<BR>» Gdal-dev mailing list<BR>»
<A
href="mailto:Gdal-dev@lists.maptools.org">Gdal-dev@lists.maptools.org</A><BR>»
<A
href="http://lists.maptools.org/mailman/listinfo/gdal-dev">http://lists.maptools.org/mailman/listinfo/gdal-dev</A><BR>»
</FONT></DIV></BODY></HTML>