I’ve been at LizardTech for almost five years now, and one thing that has always been (pleasingly) surprising to me is how much people like the plastic lizards we include with our software and give away at events. These little guys have been all over the world, and are so popular that we order them 50,000 at a time.

Last year at the ESRI International User Conference in San Diego we had a contest for you to “Show Us Your Lizards.” It was a great success; the winner brought in 31 unique LizardTech lizards from over the years. Everyone seemed to enjoy it, but the only problem was not everyone knew about it before the show started. Lots of people I spoke to at our booth said “Oh, I wish I would have known. I have dozens of them at home!”

Well, now’s your chance, because we’re doing it again. Take a look at our new contests for this year’s user conference, and show us your lizards this August in San Diego!

This week, LizardTech released the latest version of it’s GeoExpress SDK — a set of C++ libraries designed to make it easy for developers to add MrSID and JPEG 2000 support to their applications. Aside from the usual round of bug fixes and such, the big draw for this release is the number of platforms we’re now (some might say “finally”) supporting:

Windows

• Win32, VC7.1/32-bit
• Win32, VC8/32-bit
• Win32, VC8/64-bit
• Win32, VC9/32-bit
• Win32, VC9/64-bit

Linux

• RHEL3, gcc3.2.3, 32-bit
• RHEL3, gcc3.2.3, 64-bit
• RHEL5, gcc4.1, 32-bit
• RHEL5, gcc4.1, 64-bit

Solaris (SPARC)

• Solaris 8, v11 compiler suite
• Solaris 8, v11 compiler suite (64-bit)

Mac

• Mac OS 10.4 (Darwin8) / Universal (32-bit)
• Mac OS 10.5 (Darwin9) / Universal

That works out to about 13 different build configurations — yow! Remind me sometime to blog about Bob, our automated 24×7 build system…

Oh, and actually there’s one more reason to like this release: the license agreement has been made simpler, shorter, and more friendly to open source developers. While our SDK is not open source, we know a number of open source packages that wish to link it in or redistribute it, and we want to make that as simple as our lawyers will let us.

Vista users who are also administrators may have noticed that when they select the “Administer Express Server…” option from the “Tools” menu in GeoExpress 7, nothing happens. We intend to fix this in a future release, but in the meantime there are several workarounds that we don’t recommend and one that we do.

You could set GeoExpress to run as an administrator or set it to run in “XP Compatibility Mode”. However, we recommend that you let the Vista operating system fix the problem itself. Here’s how: 

When you attempt to use the “Administer Express Server…” option and it doesn’t work:

1. Close GeoExpress. A dialog appears, shown below, indicating that Vista noticed a “compatibility” issue and will make a change accordingly.



2. Click Close. 

The next time you start GeoExpress and choose Administer Express Server… from the Tools menu, all should be well.

About 250 LizardTech users took our customer satisfaction survey in April. I wanted to thank you for taking the time to tell us about how you use our products and what we can do to improve. Ninety-eight percent of you said you’d recommend LizardTech’s products to a colleague, and as a product manager that makes me about as happy as can be.

Some of you said you’d be willing to talk to me in a bit more depth about what you’d like to see in future versions and things LizardTech can do to make your life easier. I’ll be starting to make calls in early June, so thanks in advance for your help.

The JPEG 2000 standard provides for a variety of encoding options available: depending on where you sit, this makes for either a very cool experience or a very daunting experience. For the geospatial realm, where we deal with very large images, this plethora of choices is particularly important, because the choices you make at encode time can significantly affect both encode and decode performance, for both memory usage and CPU time. And, unfortunately, it’s often the case that fast encodes can make for slow decodes, and vice versa.

We’ve designed GeoExpress to default to a reasonable compromise in its choice of encoding options, and we’ve also provided a few “profiles” (predetermined encoder settings) based on NGA’s recommendations for workflows with particular requirements. Nonetheless, I’d be the first to admit that the subtle tradeoffs among tile sizes, precinct sizes, codeblock size, progression orders, quality layers, ad inf., can be truly bewildering. I give talks and write high-level articles on this JP2 stuff pretty regularly, but I’ve never quite had the time to do a stand-alone white paper discussing specifically JP2 performance and profiles using the internal benchmarking we’ve done inside here at the LizardTech Labs.

Happily — for those technically inclined, anyway — Margaret Lepley of MITRE Corp. has just done the work for me, publishing an article showing some good benchmarking analyses of these performance issues at http://link.aip.org/link/?PSI/6943/69431B/1. It is not downloadable for free, but if you’re looking for a good read on the difference that tiles and progression orders can make, I’d strongly recommend it.

JPEG 2000: fast access to large grayscale images, Margaret Lepley, The MITRE Corp.,
Proceedings of SPIE — Volume 6943

JPEG 2000 image compression allows many formatting alternatives, but users frequently have insufficient knowledge or experience to direct the choice. At compression time many of these options may seem approximately equal, but during exploitation the file structure differences can have a huge impact on access speed. This is particularly true for very large images such as those regularly used in remote sensing and many defense systems. This paper examines the impacts of JPEG 2000 options such as tiling, tile-parts, precincts, and packet ordering on large single band images, particularly in relationship to random access speed.