Mythbusting ECW decompression

Anyone who frequents the ESRI ArcGIS Desktop v10 publishing wizard would be familiar with the screenshot below. But has anyone stepped back and thought, hang on why is wavelet compression bad? For many readers, you may recall we have had an ESRI ArcPAD ECW plugin since 2003. Way back then this was powered by tiny 300Mhz mobile CPU’s and draw performance for ECW’s were instant. What has changed with wavelet technology that has meant in 2012 its something to be fearful of in server use? Have we really gone backwards?

Full disclosure: As of writing, I’m currently Product Manager for APOLLO IWS

In addition to adding overviews, using raster formats based on wavelet transforms such as ECW and MrSID will also improve performance

Further digging into the FOSS4G ’09 Benchmarking raster results with the same test data I’m about to use show Geoserver ECW (260mb) peaking at 11.2 maps/sec vs uncompressed tiled TIF raster (~16,000mb) at 13.7 maps/sec. Admittedly these results are out of date, nevertheless the performance gain of 20% came at an enormous storage cost. Image quality unfortunately wasn’t analyzed nor was JPEG compression. So there does seem to be at least a little performance penalty, in the old Geoserver version anyway and only comparing against uncompressed tiled tif. So not really a useful reference in this context.

And now the kicker that I bet half of you are salivating over. ECW SDK EULA requires a paid license from Intergraph |Â ERDAS for use in a server environment. Money!? Absurd.

So how about we actually verify these claims. Based on the variety of literature found in a whole ten minutes, there are countless people saying that JPEG compressed TIF should at least match ECW performance. ESRI tells me that wavelet compression is bad, takes longer to decompress and is proprietary. JPEG TIFF is 30% bigger but look the same and are as fast as ECW, apparently. (ref)

But if all of that is true why on Earth do Intergraph | ERDAS think they can charge for it and why is it nigh impossible to validate all these claims? Lets find out through a simple example ..

Take the uncompressed dataset (a whopping 15 gb!) and create the preferred format to â€œoptimize space, quality and speedâ€ using GDAL 1.8.1. You will see I have enabled all the optimal flags including ycbcr with average resampling

So we have at least squashed one of the referenced claims. JPEG Compressed TIFF (with yCbCr) is approximately 3.5x and not just 30% larger for this dataset. Note that the storage requirements include the gdaladdo embedded overviews as youâ€™d be surprised how many people do not factor these in..

As I wanted to investigate the decompression performance, I created additional ECWâ€™s but this time with a much lower target ratio to try and get a file size similar to the JPEG TIFF. This in theory would make the disk I/O â€œfairerâ€ in any subsequent performance test. It is however critical to note that we recommend a target ratio of 15:1 to 20:1 to retain visually lossless RGB imagery. Creating a file with such a small target will give minimal quality difference (take a look at the mp4 below)Â at the expense of storing and reading a lot more data.

-Â Â Â Â Â Â Â Â Â ECW (6:1): 263,691 KB

-Â Â Â Â Â Â Â Â Â ECW (3:1): 289,106 KB

Because of the way the compression algorithm works even with a very small target ratio the actual compression rate was still quite high due to the image having large water bodies that compress very well.

An additional JPEG compressed TIF was created with Â â€“co â€œJPEG_QUALITY=90â€ as well as gdaladdo Â JPEG_QUALITY_OVERVIEW to enhance the default 75% quality(see here). Â With all other GDAL flags being equal this produced,

-Â Â Â Â Â Â Â Â Â JPEG Compressed TIFF (90%): 587,439 KB

Now we have some data lets configure some tests. I will of course be testingÂ ERDAS APOLLO IWS v11.0.2 on Windows 7 x64. Test hardware is a quad core, 8 thread Core i7 with 8gb RAM and a single 7200k attached disk.

I usually find a visual comparison helpful to further understand any subsequent JMeter metrics. After all, how much difference is 200ms, 50ms? To do this I created an OpenLayers website with synchronised maps and on each the loadend event is captured so a JS table can be displayed to give indicative performance values. Remember, this is not a load test and so system resources are not in contention.

JMeter was configured to iterate through a small test plan of 100 WMS requests across the image in a single thread group to make a repeatable test. Unlike FOSS4G Benchmarking, the tests will all be cold-start as I hate with a passion â€œWarmâ€ tests. Servers are restarted and then each thread group is run consecutively with 1 thread. Â FYI, IWS uses internally the v4.2 ECW SDK as well as GDAL 1.7 for the TIF reading

Before analyzing the above I can already hear you thinking, damn your software just sucks reading TIF doesnt it!? You are skewing the results!

So the next step is independant verification. Without this, I would be no better than the other quotes sprouting 400% improvements compared with …Â *undisclosed*

Grab the latest Geoserver v2.1.3 jetty build.

Use the existing JDK 1.7 x64 version,

Configure two new data/layers pointing to the same TIF datasets

Enable JAI “JPEG Native Acceleration”

Coverage Access / Queue Type: “UNBOUNDED”

Suggested Tile size 512,512

Default interpolation type: Nearest Neighbour

Note: This is just a ballpark comparison. No JVM tuning or any other settings were changed from default. Remember, IWS was also an out-of-the-box configuration so I paid Geoserver some extra attention

Both servers were then restarted and JMeter test plan refreshed. Results are as follows,

Label

Samples

Average

Median

90% Line

Min

Max

Error %

Throughput

KB/sec

IWS 4326 ECW 20:1

100

116

115

159

59

278

0

8.50557115

586.0675

IWS 3857 ECW 20:1

100

171

167

214

111

261

0

5.79038796

432.9373

IWS 4326 ECW 3:1

100

111

118

154

52

193

0

8.90234132

612.3722

IWS 3857 ECW 3:1

100

174

167

214

109

644

0

5.70678537

426.2425

IWS 4326 75% TIF

100

198

203

290

74

546

0

5.01781324

313.2798

IWS 3857 75% TIF

100

225

226

302

119

444

0

4.40858793

281.9394

IWS 4326 90% TIF

100

201

206

289

74

510

0

4.927322

311.4298

IWS 3857 90% TIF

100

228

237

299

126

611

0

4.35179947

286.429

Geoserver 4326 TIF 75%

100

201

179

245

94

1449

0

4.92926505

244.4857

Geoserver 3857 TIF 75%

100

289

252

511

100

1044

0

3.43902607

194.1044

Geoserver 4326 TIF 90%

100

194

169

238

103

902

0

5.1266277

261.2856

Geoserver 3857 TIF 90%

100

276

257

469

98

606

0

3.6101083

208.9514

So what does all this mean?

Firstly, IWS TIF throughput performance was very similar to Geoserver’s. I don’t really want to get into arguments with OpenGeo/Geosolutions on this as we could be here for days tuning and is not really the point of the post. For all intensive purposes one can adequately say the APOLLO IWS TIF implementation is not encumbered in any way

For many of our customers with hundreds of terabytes and even petabytes of image data, the business justifications are all there for license aquisition. Whether it be talking to your IT area who has to manage increasing SAN costs, the data capture area who want to ensure quality is retained, or the end customer who just wants the imagery served to them as quickly as possible. The license fees are what we determine to be fair market price, but unfortunately many would prefer to ignore the benefits (or pretend they didnt exist) and in the end cost their organization more money in the process.

I suspect this post will attract the usual suspects, but if i can leave one thing in your minds it would be the following tweet from me,

Take-aways

Wavelet based formats ECW, JPEG2000, MrSID should never be tainted with the same “wavelet” brush and grouped together. They do not perform the same and makes about as much sense as me grouping the variety of compression and structure options available for GeoTIFF and just saying “Geotiff is slow”

If your current server software does in fact perform slower reading ECW then that is likely an architectural constraint or a poor implementation of the ECW SDK. If you are still using a DCOM multi-process based software then your usage will vary. Fear not though, there is a better solution out there

Now, you did your tests without load contention, and I’m wondering if some of the mythology around wavelets is related to the fact that they really do (did?) slam the CPU. Certainly I found that Back In The Day. Or maybe things just have improved a lot since Back In The Day.

However, even if they haven’t improved (and that’s unlikely), one independent thing that’s changed a great deal since Back In The Day is that the relative price of cores compared to I/O has gone down down down, so I think it’s time to re-evaluate the wavelet value proposition. Cause if I have 64 cores at my disposal (and these days, who doesn’t?), a little extra CPU time is not the end of the world.

Indeed CPU time is not the end of the world; especially when it is offset by reduced disk I/O and increased RAM utilisation. As you point out the increase in cores/clock speed/SSE instructions has meant the value proposition has vastly improved and certainly not gone backwards. Anyone who says otherwise well … i’m not sure.

Slamming the CPU kind varies. Certainly JPEG2000 is more expensive than ECW and I’m not really in the position to comment on MrSID. Which is primarily why people need to stop grouping the formats together as usage always will vary

The circular argument on wavelet compression usually hinges these days around “but storage is cheap now”. Sadly that just goes back to my swallowing one-liners comment as that’s never been the only advantage