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.