Good things come in small packages. The types of packages that have made the headlines in the imagery world for the past few years had the extensions .SID (from LizardTech) and .ECW (from Earth Resource Mapping). Both of these companies, and others, are exploring a new format on the block: JPEG 2000. That format, actually an ISO standard, traces part of its existence back to a German company, LuraTech, which was heavily involved in the development of the standard. LuraTech has had a technology toolkit for JPEG 2000 for several years and recently completed its geospatial implementation for JPEG 2000. I spoke with the company’s President, Carsten Heiermann, about the format and its place in geospatial technology.

   First off, Heiermann helped me understand the different parts of the JPEG 2000 specification. Of particular importance to LuraTech are Part 1 and Part 6. Part 1 documents how compression is done. That’s the part that enables software vendors to build software to produce or view JPEG 2000 images (Figure 1). Part 6, which LuraTech co-authored, deals with mixed raster content (MRC). What’s that? Heiermann explained that it’s a model for compressing color scans. It divides the document into three layers (Figure 2): images (done with JPEG 2000/ Part1); text or line graphics (anything bi-tonal); and a color layer, which can describe the background or the bi-tonal parts. Why is it important to geotechnology people? It allows for very high compression rates (400:1, 500:1) and maintains the clarity of delicate graphics, like annotation. That makes this type of compression particularly good for scanned maps. LuraTech was the first company to implement the ISO standard version of MRC in the JPEG 2000 standard in its software, and already has several key users, including the German government and the California department of Transportation, which have stored their paper maps in JPEG 2000.

   The most exciting part of JPEG 2000 for Heiermann is clearly that it’s an ISO standard. The company for many years sold its own proprietary compression solution, LuraWave that’s better known in Europe than in the U.S. In time, the company became active in the JPEG 2000 Committee of ISO and once JPEG 2000 was approved at the end of 2001, LuraTech set out to implement it. The staff took what it had learned both in the process of creating the standard and in listening to users and built its own JPEG 2000 compression and decompression developer tools. From its intimate relationship with the specification, LuraTech’s engineers knew of its flexibility, in particular, the special options inside that could be tweaked for extra performance, such as region decoding and progressive decoding. From watching the market, LuraTech could see demand growing. So, for example, when International Land Systems (which developed LizardTech’s viewer, GeoExpress View) started getting pressure to support JPEG 2000, LuraTech felt sure it was on to something. More recently, a presentation by LuraTech’s CTO Klaus Jung at an Open Geospatial Consortium meeting introducing JPEG 2000 drew a large crowd. And, last year, ESRI committed to supporting the format. Though many readers may not yet have touched JPEG 2000 files, Heiermann is confident “we will reach critical mass in supporting JPEG 2000.”

   JPEG 2000 implementations, some say, are faster than the proprietary formats. Others offer that that are “just” as fast. Interestingly, the compression and decompression processes take roughly the same amount of time, something referred to as symmetric encoding/ decoding. When you speak to Heiermann, these discussions are secondary: it always comes back to the fact that JPEG 2000 is an open standard.

   I pointed out that sometimes it can be tough for users to see the “real world” difference between a format that’s a standard and one that is not. I noted that even though LizardTech and Earth Resource Mapping and even LuraTech’s proprietary formats are proprietary, they do work. Heiermann acknowledged that, and pointed out that you cannot share a .SID file with a colleague unless he or she has that company’s software. With an open standard, there may be several different products that read and write the format, enhancing interoperability. From a business perspective, he continued, should one vendor provide a solution that’s superior to another, or should one company shut its doors, it’s possible to switch to a second solution with very little down time.

   JPEG 2000 was originally written to be a generic image format. That meant that in its original form there was no formal method defined to store image metadata, typically used in GIS and imaging software to “know where the image is on the earth.” LuraTech and other companies put forward a suggestion to the ISO JPEG 2000 committee that defined where in the XML structure (actually GML, geography markup language, an OpenGIS specification that encodes geospatial data) of  such data should go. That place, called a marker, was added into the specification. What data exactly should go in that box, however, the JPEG 2000 committee did not specify. That job fell to the Open Geospatial Consortium.

   At a meeting in Vancouver in December of 2003, LuraTech and several other companies put forward a suggestion regarding the subset of data that should go in the box (Figure 3). LizardTech and Galdos Systems put forward a second suggestion.  Two other suggestions have also been proposed.  At this point four different proposals are being considered by the OGC membership. 

   There has been some confusion over which organization, ISO or OGC, should determine the contents of the box. ISO normally creates content specifications for electronic and hard copy documents and OGC normally creates interface specifications for use in communication between computer software components such as Web services. The JPEG 2000 box  will hold information that does both.  OGC is working to conduct an interoperability experiment to determine which content format “works the best.” Based on that work, OGC  expects to release a proposal to ISO and the public this winter. What’s a vendor to do before that work is complete? If the vendor is LuraTech, the answer is to let the user decide. The company’s current JPEG 2000 offering for geospatial (SDK GEO edition) includes support for all four different solutions.

   Since remote sensing data comes in many different forms, beyond just simple images, such as hyperspectral and others, I asked Heiermann why I hear little about the use of compression for those types of images. He’s quick to note that JPEG 2000 has all the smarts to handle the extra channels and high bit depth of these sorts of files, but that he too has not seen the demand. I’ll suggest there’s simply less of that sort of data in use or that it need not be shared as widely as “simpler” images.

   Where then is JPEG 2000 making a big splash? Heiermann notes that most of the company’s revenue currently comes from one area: medical imaging. That industry was on board with JPEG 2000 early, developed its own industry

standard, DICOM, within JPEG 2000 and the rest is history. Heiermann notes that JPEG 2000 is no longer even spoken about in the medical imaging area; “it’s already invisibly inside all of the software.” So, how’s geospatial use doing?  “It’s growing” he reports, citing geospatial users in the U.S. including BAE Systems, Northrop Grumman, General Dynamics and the military.

   To close, I asked Heiermann to look ahead five years. Would the company still be offering its proprietary compression solution? He suggests that by then, there will be no new business in that area. Even now, he notes, the company is not actively selling its proprietary solution. Existing customers are moving to JPEG 2000 solutions, sometimes running both concurrently as they make the transition. New customers invariably purchase the open standards-based solution over the proprietary one.

©Copyright 2005-2021 by GITC America, Inc. Articles cannot be reproduced,
in whole or in part, without prior authorization from GITC America, Inc.

PRIVACY POLICY