<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I've found setting <span class="Apple-style-span" style="font-family: Times; font-size: medium; ">PHOTOMETRIC=YCBCR to allow much higher compression when using jpeg compression in gtifs.</span></div>
<div><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><br>
</span></div>
<div><span class="Apple-style-span" style="font-family: Times; font-size: medium; ">Mike</span></div>
<div><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><br>
</span></div>
<div><span class="Apple-style-span" style="font-family: Times; font-size: medium; ">
<div>
<div>
<div>-- </div>
<div>Michael Smith</div>
</div>
<div>US Army Corps</div>
<div>Remote Sensing GIS/Center</div>
</div>
</span></div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Jan Hartmann <<a href="mailto:j.l.h.hartmann@uva.nl">j.l.h.hartmann@uva.nl</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, December 18, 2012 5:47 AM<br>
<span style="font-weight:bold">To: </span>Jukka Rahkonen <<a href="mailto:jukka.rahkonen@mmmtike.fi">jukka.rahkonen@mmmtike.fi</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>" <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [gdal-dev] Q: on gdalwarp of ecw file<br>
<span style="font-weight:bold">Resent-From: </span>Michael Smith <<a href="mailto:michael.smith@usace.army.mil">michael.smith@usace.army.mil</a>><br>
</div>
<div><br>
</div>
<div>
<div text="#000000" bgcolor="#FFFFFF"><font face="Times New Roman,Times,serif">Thanks Jukka, very informative. I'll start with jpeg compressed tiffs and will do additional tests next year. I'm on a Cloud environment nowadays, so it's easy to set up clean VMs
for testing. Any suggestions for experiments with different raster formats would be very welcome.<br>
<br>
Jan<br>
<br>
</font>
<div class="moz-cite-prefix">On 12/18/2012 12:33 PM, Jukka Rahkonen wrote:<br>
</div>
<blockquote cite="mid:loom.20121218T115628-779@post.gmane.org" type="cite">
<pre wrap="">Jan Hartmann <j.l.h.hartmann <at> uva.nl> writes:
</pre>
<blockquote type="cite">
<pre wrap=""> Hi Even, are there any
benchmarks to compare (uncompressed) gtif with the three formats
above? My production maps are always tiled to 2000*2000 pixels,
all zoomlevels precomputed. Very efficient with uncompresssed
gtif, but they take lots of space. How much slower are these
formats?
Jan
</pre>
</blockquote>
<pre wrap="">Hi,
Here are some 6 years old numbers from some Mapserver tests:
<a class="moz-txt-link-freetext" href="http://permalink.gmane.org/gmane.comp.gis.mapserver.user/23540">http://permalink.gmane.org/gmane.comp.gis.mapserver.user/23540</a>
The speed feels now rather slow compared with the feeling I have from our recent
services but differences may be alike. Or then they are not because drivers are
not the same anymore and new hardware can suit better for one than for another.
We are using aerial images mostly as JPEG compressed tiffs now but I have not
bothered to do any timings lately. They save 90-95% of disk space, they are not
much slower and users have not noticed the difference in quality so for us the
choice was pretty easy.
It is usually too simplified to say that some file format is slower that some
other because there are so many other factors also in play. JPEG200O is an
infamous example. It is a complicated file format and many software are very
slow with big geospatial JPEG2000 images, but there are applications which can
handle them very fast. Sluggish software does not necessarily mean that the
format itself is slow. Six year old numbers 270/120/24 images per minute for
tiff, ECW, and JPG2000 with Kakadu prove mainly that there must have been
something wrong in how Kakadu and GDAL were working together at that time.
You can get the best information about the real speed in your environment by
making your own tests. Others will praise you later if you make controlled tests
and publish the arrangement and results somewhere for future references.
Unfortunately I do not remember myself how I did my own tests but I believe I
was using FWTools 2.0.4 binaries.
_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</span>
</body>
</html>