How Express Server Software Improves Geospatial Image Delivery

Transcription

1 How Express Server Software Improves Geospatial Image Delivery A LIZARDTECH WHITE PAPER contact: Jon Skiffington jskiffington@lizardtech.com

2 Written by Matt Fleagle Published June 2012 Copyright 2012 Celartem Inc. dba LizardTech, 1008 Western Avenue, Suite 200, Seattle, WA Unauthorized use or distribution prohibited. Access to and use of this code is permitted only under license from LizardTech. All rights reserved. LizardTech, MrSID, GeoExpress, Express Server, Spatial Express, and Express Suite are registered trademarks in the United States and LiDAR Compressor and the LizardTech, GeoExpress, Express Server, Spatial Express, Express Suite, LiDAR Compressor, ExpressView and GeoViewer logos are trademarks, and all are the property of LizardTech. Unauthorized use is prohibited. ii

3 TABLE OF CONTENTS Introduction... 1 Express Server Overview... 2 How Express Server Works... 3 The Workflow... 4 Storage... 4 Image Formats... 4 Catalogs... 5 Protocols... 6 Client Devices... 6 Scene Extraction... 6 Express Server APIs... 7 The WMS and Web APIs... 7 The JPIP API... 8 Configuration Files The Base Configuration File The Catalog Configuration File The JPIP Configuration File Performance Conclusions Further Reading Glossary iii

4 iv

5 Abstract: Advancements in the collection of geospatial imagery in recent years have resulted in the increasing availability of greater quantities of higher quality imagery, and that availability has been matched by increasing demand as business and nonbusiness users have grown to expect high-quality geospatial imagery in more applications on more devices. What has not changed is that the bandwidth available for transferring this imagery is limited, which means that, in general, delivery is the bottleneck in any workflow involving image repositories and end users. This paper describes a software solution that takes advantage of the architecture of the wavelet-based MrSID and JPEG 2000 image formats to deliver high resolution imagery to more users, faster, on any device and over any connection. INTRODUCTION The role of geospatial imagery in civil and defense enterprise has increased steadily over the past two decades. The integration of geospatial imagery into commercial software applications has been more recent and dramatically swift. In both cases, the benefits users realize in the access to georeferenced satellite or aerial images have rapidly solidified as essential, non-negotiable elements of logging on. Increasingly, if the purpose of an application has anything to do with location or locating, then it will need to integrate geospatial imagery. Moreover, technologies available for image collection continue to improve, so that higher resolution ( more detailed ) imagery and imagery having more than three bands (multispectral and hyperspectral imagery) is increasingly available and at lower cost, with the result that from a business perspective, it becomes imperative to provide access to this better and better imagery. From a computing standpoint, the operational cost of handling geospatial imagery is high. That is, image data require a lot of numerical description, so image files are extremely large, the more so when there are additional bands. This presents a fundamental problem for digital image distribution because it forces a choice between the delivery of smaller images (lower resolution and less detail) and untenably slow delivery of larger, more useful ones, the latter choice rendering it impossible to do any work with the imagery and the former defeating the purpose of collecting high resolution imagery in the first place. Solutions to the problem of imagery delivery can be seen as being divided between hardware solutions and software solutions. With enough server hardware, the limitations of processors and bandwidth can be overwhelmed by essentially chopping high-resolution imagery up into pieces small enough to be distributed over networks and then reassembling them in the viewing client. Enormous server farms enable popular image providers such as Google and Bing to distribute high resolution imagery quickly. The software solution addresses the data itself, generally through compression. While hardware-based solutions may incorporate compression and other software-based technologies, LizardTech Express Server image serving software (hereafter Express Server ) is entirely a software solution. That is, Express Server significantly increases the speed at which existing web servers deliver high-resolution imagery. 1

6 How Express Server Software Improves Geospatial Image Delivery This paper s purpose is to describe how Express Server achieves this improvement in delivery performance and to provide some benchmarking data showing some of the delivery speeds that can be realized with an Express Server workflow. EXPRESS SERVER OVERVIEW Express Server is a software application for rapidly distributing large datasets of raster imagery that have been compressed to MrSID or JPEG 2000 format. Express Server enables an existing web server to provide instant viewing of high-resolution aerial photographs, satellite imagery and other digital content on both wireless and broadband devices. At its core Express Server is an engine that converts URL requests from client devices into images for delivery. The engine includes portions of the GeoExpress SDK with its readers and writers and is accessed by WMS and web APIs. Figure 1: Basic Express Server Architecture Web Browser WMS Client Cascading WMS Server Applications AutoCAD Map ArcGIS Image Server ArcIMS Bentley Microstation ArcGIS Server ArcMap JPIP Client Web Server HTTP Microsoft IIS or Apache Web Server Express Server Image Serving Software software WMS API Web API Express Server Engine JPIP Server (optional) Image Data File System Spatially Indexed Mosaic Oracle Spatial File System 2

7 A LizardTech White Paper Express Server works with Microsoft IIS and Apache web servers to extract image scenes from MrSID and JPEG 2000 imagery including multi- and hyperspectral data that is stored in file systems (as individual images or as spatially indexed mosaics) or in an Oracle database and deliver them to viewing clients in a variety of formats. It s the wavelet-based MrSID and JPEG 2000 formats that enable Express Server to deliver imagery so quickly, as we ll see later. In addition to its own API, Express Server supports version 1.1 of the OGC Web Map Service (WMS) standard and, through the JPIP Server, the JPEG 2000 Interactive Protocol (JPIP). Express Server s JPIP Server is an optional component with a separate engine technology for progressively streaming imagery from a server to a client to support image use in bandwidth-constrained environments. HOW EXPRESS SERVER WORKS When an image request comes in to an IIS or Apache web server, that web server recognizes the request as belonging to one of the Express Server APIs. The Express Server engine then: determines what reader is to be used locates and opens the image after consulting the various caches extracts the requested scene based on requested parameters such as level (resolution), width and height, and upper left coordinates engages an image writer based on the specified output format delivers the image The figure below illustrates this workflow. Figure 2: Express Server Workflow 3

8 How Express Server Software Improves Geospatial Image Delivery The Workflow Express Server uses the HTTP protocol to deliver imagery to computers and laptops, tablets, phones and other handheld devices any client device that hosts a web browser or that can be used to work with a GIS. The network connection can be wireless or conventional and can be of any bandwidth. Images are stored on file systems or in an Oracle database to which Express Server has access. Express Server supports MrSID, JPEG 2000 and NITF formats as source imagery. These image formats have the extensions.sid,.jp2 and.ntf. Express Server keeps track of these images singly and in groups as catalogs, which can be browsed and explored. A catalog can be an array of folders with images in them, or, more typically, a single, indexed image called a mosaic that is made from a number of smaller images. Catalogs are managed by the Express Server administrator. Express Server receives a WMS request, a web API request, or a JPIP request (request for a JPIP connection); these protocols sit on top of the HTTP protocol. They are simply different ways of requesting imagery. The components of a request may represent a query as to what catalogs are available for viewing, or it may ask for a particular catalog. The precise composition of the URL request is determined by the protocol being used and the associated API. Similarly, the first scene returned by Express Server is determined by a number of factors shaped at the client end. In a web browser, a thumbnail of the catalog is usually the first returned image. When a user clicks the thumbnail, the image is typically opened at a low resolution for overview. Depending on the client s toolset, a rectangular portion of this overview image may be drawn for zooming into or a click on the image will return image data from the next larger resolution or zoom level and recenter the scene on the coordinates corresponding to the location of the click. In a WMS environment, image catalogs are returned as layers whose bounds correspond to the extents of the map the user is creating or working with in their particular GIS application. As with web browsers, scene extraction and return over the WMS protocol follows the workflow of the particular application. The JPIP protocol is significantly different in that what is being delivered to the client is not images or even pixels but wavelet coefficients representing regions of images at desired resolutions. JPIP thus requires a more sophisticated client that can receive and translate these transmissions before the user can see any image at all. STORAGE Imagery served by Express Server need not reside on the same hardware as the Express Server installation. It can be stored in any network file system or in an Oracle database that Express Server has permission to access. IMAGE FORMATS For source imagery, Express Server supports MrSID, JPEG 2000 and NITF. MrSID and JPEG 2000 are both wavelet-based formats that facilitate the efficiencies of raster data storage and distribution that high compression enables. Extracted scenes from MrSID imagery in particular are returned extremely quickly. Because their wavelet-based algorithms naturally and automatically result in multiple resolutions of an 4

9 A LizardTech White Paper image within the compressed image file itself from the full resolution image down to a low-res thumbnail both formats provide the high image quality required by geospatial professionals yet obviate costly and time-consuming image pyramiding. MrSID images are identified by generation and may be MrSID Generation 2 (MG2 ), MrSID Generation 3 (MG3 ) or MrSID Generation 4 (MG4 ). There are important differences among them. MG2, the oldest version, has a 2-gigabyte file-size limit and does not support lossless compression. MG3 introduced support for lossless compression and a number of other features including reprojection, color balancing, despeckling and encoding areas of interest, and removed the 2-GB size limit. MG4 is the most recent evolution of the MrSID format. In addition to mosaicking datasets together, color balancing raster imagery, and manipulating data in other ways as do MG2 and MG3, MG4 enables geospatial professionals to losslessly compress 3-banded and multispectral (including hyperspectral) geospatial data so that they can make full use of the most up-to-date imagery. MG4 also introduced support for alpha bands, which remove the problem of speckling in the transparency areas of mosaics. The following table illustrates the differences between versions of the MrSID format and JPEG Table 1: Support for Common Requirements in LizardTech File Formats Situation/Requirement Supported by Output File Format MG2 MG3 MG4 JPEG 2000 Lossy output with maximum 3 bands, cropping but no advanced encoding, output less than 2 GB* Advanced encoding (reprojection, color balancing, despeckling, area of interest encoding, etc.) Output file size greater than 2 GB Lossless output Mosaic that has MrSID tiles as input Multispectral input Optimization Alpha band Signed datatypes (e.g. s8, s16) Arbitrary band mapping Per-band compression NITF (National Imagery Transmission Format) is a suite of standards for the exchange, storage, and transmission of digital-imagery products and image-related products within the U.S. Department of Defense and the Federal Intelligence Community. NITF supports compression to JPEG 2000 format. By default Express Server delivers extracted scenes as JPEG images. Other options for final delivery format are PNG (.png), GIF (.gif), TIFF (.tif and.tiff) and Bitmap (.bmp). CATALOGS Express Server treats every image as partly or wholly constituting a catalog. The catalog is the basic edifice used by Express Server to organize images and house information about them and instructions 5

10 How Express Server Software Improves Geospatial Image Delivery about how to treat them. A catalog of images is made accessible to Express Server through its inclusion in an editable XML file called a catalog configuration file. For the purposes of WMS, a catalog is the same thing as a layer. The catalog configuration file instructs Express Server in how to treat catalogs. It informs Express Server, for example, of all the catalogs available to it, and specifies not only basic properties of each catalog such as its name, location and description, but also things like the requirement of a watermark, the maximum size of an image request, and the size and format of thumbnails generated by Express Server for images in that catalog. Whether and how a catalog is spatially indexed a requirement if the catalog is to be published as a WMS layer is also controlled via the catalog configuration file. The catalog configuration file can have any number of catalogs listed in it. We ll see an example of a catalog s listing in the catalog configuration file later on when we look at some of that file s more interesting elements. PROTOCOLS Express Server rapidly distributes large geospatial images using the WMS or JPIP standard, so very little time must be spent customizing applications or retraining users. These interfaces and Express Server s own web API sit atop the HTTP protocol. The Web Map Service standard (WMS) provides a simple HTTP interface for requesting georeferenced map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more georeferenced map images (returned as JPEG, PNG, etc.) that can be displayed in a WMS-enabled GIS application. The JPIP client/server communication protocol is defined in Part 9 of the JPEG 2000 suite of standards, (ISO/IEC ). JPIP progressively streams the wavelet coefficients for a requested part of a picture, which saves bandwidth, computer processing on the server, and time. It allows for speedy viewing of a large image in low resolution or a higher-resolution part of that same image. Using JPIP, it is possible to stream large images (for example 1 gigapixel) to relatively lightweight hardware such as PDAs. CLIENT DEVICES Because it is standards-based, Express Server s architecture enables image delivery quickly to virtually any client viewer, regardless of the device or the amount of bandwidth. Express Server s output is simply an image, delivered via the HTTP protocol, readable by any of the web browsers with which even the smallest devices with a viewing screen now come equipped. Express Server also supports Web Map Service (WMS), which is supported by virtually all GIS applications. Scene Extraction What enables Express Server to serve image data so quickly is that its design takes advantage of two aspects of the wavelet-based MrSID and JPEG 2000 compression formats: a multiresolution image file and selective decompression. 6

11 A LizardTech White Paper Conventional image serving schemes require the construction of image pyramids, which are expensive in terms of money, time and storage. Image pyramids comprise copies of each image at various resolutions so that when a client requests an image or a scene at a particular resolution a close approximation can be delivered. Image pyramids take up an enormous amount of storage space in addition to the cost in time to create them, and must be completely recreated each time an image is altered. With MrSID and JPEG 2000 encoding, images are compressed (losslessly, as a best practice) such that numerous resolution levels of an image, from icon and thumbnail all the way up to the full original resolution, are the natural result of compressing the image. Because of the way the actual bits representing the image are stored, any portion of an image can be decompressed at any resolution level without the necessity of decoding the entire image. Express Server is built specifically to take advantage of this selective decompression feature of MrSID and JPEG 2000, extracting the requested scene quickly and converting it to an image scene in one of several output formats. Depending on cache settings, which we ll discuss later on in this paper, subsequent requests for image data from the same areas of the same images will not require decompression at all, so that over time the delivery of scenes from a given image repository can become even faster. Express Server APIs Express Server responds to a request formulated according to one of three APIs: the WMS API, the web API, or the JPIP API. The request is in the form of a URL. THE WMS AND WEB APIS Though the syntax of the requests is different, the WMS API is functionally equivalent to the web API. Express Server s web API enables web browsers to make requests for images or scenes from images according to various specified parameters. The URL request can be formed either through the clicking of graphic elements or by manual entry in the URL field. The WMS API essentially does the same thing, but WMS was created as a standard means of importing data in diverse locations into a GIS. The WMS API enables geospatial applications to pull in Express Server catalogs as layers. A catalog is WMS-enabled (available for WMS requests) when it is spatially indexed. This means that Express Server understands how to fit all the images in a catalog into a mosaic and has assigned the catalog a coordinate reference system (CRS) in the form of an EPSG code. Instead of having to open each image in the catalog to find out where it belongs in the world and in the mosaic, Express Server consults a single index file that contains this information for all the images in the catalog. The following two requests both return a summary of available catalogs on an Express Server installation hosted at demo.lizardtech.com. The first is a WMS API request, the second a web API request. Express Server supports version of the OGC WMS specification via the GetCapabilities and GetMap calls. The reply sent back by Express Server is an XML document (which in the web API gets turned into an html page displaying thumbnails of the available catalogs). The above URLs are live and will each return 7

12 How Express Server Software Improves Geospatial Image Delivery XML output. A user will not normally see the XML, but a look at some XML excerpts will show some interesting items. Below is the return from a WMS GetCapabilities request showing one catalog. Note that it is referred to as a layer, and that the extents are described in terms of a bounding box. <Layer opaque="1"> <Name>Florida</Name> <Title>Florida</Title> <SRS>EPSG:26917</SRS> <LatLonBoundingBox maxx=" " maxy=" " minx=" " miny=" " /> <BoundingBox SRS="EPSG:26917" maxx=" " maxy=" " minx=" " miny=" " resx=" " resy=" " /> <ScaleHint max=" " min=" " /> </Layer> Note: For more information about how the various XML elements are used in WMS requests and what their values signify see the Further Reading section at the end of this document. Below is the same catalog listed in the return from a web API browse request. <Item georgn=" , , , " name="florida" srs="epsg:26917" /> Following is a WMS request to open the catalog which it identifies as the layer called Florida. We ve broken up the URL into rows so it can be viewed more easily. &VERSION=1.1.1 &REQUEST=GetMap &LAYERS=Florida &SRS=EPSG:26917 &BBOX= , , , &WIDTH=600 &HEIGHT=500 &FORMAT=image/jpeg &TRANSPARENT=FALSE In the web API, the same catalog is requested using the getimage command, as follows. cat=florida&item=iserv-catalog-index &rgn= , , , &geo=true &wid=600&hei=500&method=scale &oif=jpeg The above examples demonstrate the basic methods by which clients retrieve imagery and information from Express Server. They are live examples that both open the same Florida mosaic. THE JPIP API The JPEG 2000 Interactive Protocol, or JPIP, is a specification for progressively streaming imagery from a server to a client to support image use in bandwidth-constrained environments. 8

13 A LizardTech White Paper Part 9 of the JPEG 2000 set of standards (ISO/IEC 15444), JPIP uses the same data structures as the file format to incrementally deliver pieces of the image to a requesting client, with no algorithmic overhead to preprocess or transcode the image. Each of these delivered pieces is fully indexed in that the JPEG 2000 decoder knows where in the image that data belongs in terms of its spatial position, resolution, and quality contribution. At any point in the process of downloading the data from the server, the smart client can translate the bytes currently available to some approximation of the image. If only a small number of bytes have been transferred the image will be of low resolution and/or low quality; as the user idles over a scene, more data is transferred and the representation of the image increases in resolution and quality. Express Server s JPIP API is an optional component that works with any JPIP viewing client. In a JPIP transaction, the viewing client sends a request for a connection along with some information about how large of a chunk of image data it wants to receive at a time and a summary of what it knows about the imagery it hopes to view. The server sends back a channel ID number and opens a transfer session. The channel ID number identifies the session and is used by the client in each subsequent request for more data. Because Express Server s JPIP server component streams wavelet coefficients instead of sending images there is always something to render in a JPIP viewer. Image detail is filled in as it arrives. This can be taken advantage of in several ways depending on the capabilities of the viewing client. For example, the image data might be requested in such a way that priority is placed on rendering the entire image at lowquality before more detail is rendered in any given portion of the image, or the opposite might be requested: an area of interest can be specified that receives priority as the data is being delivered, and where the maximum image detail is filled in first. In practice, a user might open the image as a layer in a GIS application and, before the image renders at full quality, draw a rectangle specifying an area of interest. At that point, Express Server stops filling in the entire image and focuses on supplying image data for just that area of interest. Let s compare two requests for data that Express Server might receive from a JPIP viewer, with some important parts highlighted: xl<0>&len=2000&cid=jph_fffc70d c1: ntext=jpxl<0>&len=2000&cid=jph_fffc70d c1 Note: For more information about how the various XML elements are used in JPIP requests and what their values signify see the Further Reading section at the end of this document. Let s look at the parts we ve highlighted. In both URLs you can see the channel ID number (cid) at the end. Also, the desired chunk size or length of the stream (len) is 2000 bytes in both. You ll notice that in the first URL, fsiz (the size of the entire image) and rsiz (the size of the region of interest) are the same 482 pixels on the x axis and 813 on the y axis and that the roff (region offset) has a value of zero, which means that there is no particular region of interest being specified. The region starts in the 9

14 How Express Server Software Improves Geospatial Image Delivery upper left corner of the image (0,0) and is the same size as the image. In this case the detail for the entire image will be filled in at an even rate. But in the second URL (see Figure 3 below) there is an offset of 3228 pixels on the x axis and 2480 on the y axis and the size of the area of interest is only a small part of the image 267 pixels by 169 pixels. In this case Express Server will send the detail for that smaller region first. Figure 3: A JPIP Region of Interest 4849 roff=3228, Region of Interest rsiz=267,169 fsiz=4849,6497 This is just one application of the capabilities of the JPIP protocol in Express Server software. Configuration Files Configuration files are XML files that are edited by an administrator to set up an Express Server installation, direct its behavior, and specify how imagery is made available for delivery. In the current and previous versions of Express Server, these configuration files must be edited by hand (using an XML editor to directly alter the XML), but future versions of Express Server will employ a graphical user interface that will enable editing the configuration files by means of easy-to-use checkboxes, drop-down menus and text fields. There are three main configuration files. The base configuration file, iserv-cfg.xml, governs certain operating characteristics of Express Server. The JPIP configuration file, jpiphost.exe.config, controls how the JPIP Server operates. The catalog configuration file, cat-cfg.xml defines the image catalogs and their properties. 10

15 A LizardTech White Paper XML files are composed of elements and subelements. Some elements may not appear in the file unless and until an administrator changes a parameter from its default setting. Note: The names of the configuration files, as well as some of their elements and properties and their organization, may change in future versions of Express Server. The names and sample files used in this document are correct as of version 7.0. THE BASE CONFIGURATION FILE The base configuration file ( iserv-cfg.xml ) instructs Express Server in how to cache image data and perform other basic functions in much the same way that the catalog configuration file instructs it how to treat the images in the catalogs. There are ten elements in the base configuration file that can be employed to fine tune Express Server s operation, but here we will look at just a few of the elements related to caching. The Caches Decoding imagery requires CPU processing. Express Server can reduce these CPU requirements by saving raw pixels in the disk cache. This can improve performance significantly for active sites. However, this comes at the expense of increased disk usage. Express Server offers three distinct strategies for caching pixels, each represented by a distinct cache. Each of these caches lives on disk and its size, location and pruning interval are all determined by the DiskCache element. The DiskCache Element In response to requests, Express Server may cache certain data to disk, including image thumbnails, frequently requested image extractions, and raw pixels. The DiskCache element specifies the directory in which these temporary files are stored and policies regarding their removal. The DiskCache element has three editable attributes that specify the directory path in which Express Server stores the temporary files, the amount of disk space Express Server can use for the disk cache and the number of minutes between automatic purges of the disk cache. The ImagePixelCache, WarpPixelCache and IndexPixelCache Elements Each of the following elements supports editable attributes for fine tuning the caching strategy to optimize performance. These attributes specify the width and height in pixels of each block saved in the cache, the minimum allowable ratio of requested scene pixels to decoded tile pixels, and the maximum image resolution at which caching occurs. The ImagePixelCache strategy involves caching the pixels from images as they are decoded. This strategy may be useful for sites that have many different images to serve and are not using the spatial index or WMS features of Express Server. LizardTech recommends enabling this strategy for non-wms sites. The IndexPixelCache strategy involves caching the pixels decoded from a spatial index. A spatial index is a special type of Express Server catalog that dynamically combines a collection of spatially related images into a single mosaic. WMS GetMap requests use the spatial index. When this strategy is 11

16 How Express Server Software Improves Geospatial Image Delivery employed, the pixels from the index are cached, rather than from the individual images that are included in the index. LizardTech recommends enabling this strategy for WMS sites. The WarpPixelCache strategy involves caching pixels after they have been reprojected or warped. This only affects WMS GetMap requests that require reprojection. LizardTech recommends enabling this strategy for WMS sites in which most requests require reprojection. Sample iserv-cfg.xml File Following is a sample of a valid iserv-cfg.xml file, complete except that comments have been removed and the disk and pixel cache elements we discussed have been highlighted. <?xml version="1.0" encoding="utf-8"?> <IservConfig> <Logging level="notice" access="true"/> <DiskCache root="c:\lizardtech\expressserver7.0\imageserver\var\cache" size="512" interval="360"/> <ImagePixelCache enabled="false" tilewidth="200" tileheight="200" utility="0" /> <IndexPixelCache enabled="true" tilewidth="200" tileheight="200" utility="0" maxmag=="0.06" /> <WarpPixelCache enabled="false" tilewidth="200" tileheight="200" utility="0" /> <Algorithms scaleresample="bl" warpresample="bl" warperrorthreshold=".333" scalemagthreshold="0.5" /> <ImageManager imgcachesize="500" itemcachesize="1000" maxconcurrentextractions="50" extractiontimeout="50" extractionlistsize="50" extractioncachetrigger="2"/> </IservConfig> THE CATALOG CONFIGURATION FILE The catalog configuration file, introduced earlier, also has ten potential elements and again we are going to look at just a few of the more interesting ones. 12

17 A LizardTech White Paper The Property Element The Property element defines a single property of a catalog. Catalogs may have many properties or none. A Property element can be made to affect a single Catalog element or all catalogs listed in the catalog configuration file. Each property must have a name and a value attribute and can optionally have a lang attribute, which identifies the language that the property is expressed in. Certain special catalog properties are recognized by Express Server for various purposes, but a property can have any name and any value. The SpatialIndex Element This is a pretty simple element but it is one of the more important ones because when its enabled attribute carries a value of true (which is the default), the catalog in which this element is included is available to be imported as a WMS layer into virtually any geospatial application. Besides the enabled attribute it also has an attribute called classid, which identifies the spatial index implementation. The classid attribute is set by default and should not be changed unless you have installed a custom spatial index implementation. The BufferMergeRule Element When two images overlap in the creation of a mosaic for delivery Express Server s mosaicker must choose between the top or bottom pixel. It might seem obvious that the top pixel should be used if its value does not equal the no-data value, but because lossy compression may introduce slight changes in the values of the no-data pixels, some extra care is required to avoid mistaking these drifted no-data values for valid image data and thus to reduce tile boundary artifacts. For example a black pixel, which has the sample values 0,0,0, may end up being 0,0,1 or 0,1,0 after compression, which will still look black to the eye but not to the mosaicker. The mosaicker, in seeking out true black pixels to make transparent, treats this as valid image data instead and writes it to the output image, introducing a near-black pixel instead of the correct one from the other tile, an effect that when multiplied along a boundary or around the collar of an image is called speckling. Figure 4: Speckling at the edge of an image. 13

18 How Express Server Software Improves Geospatial Image Delivery The BufferMergeRule element is helpful here because it enables flexibility in what is otherwise a hard rule. By means of its method attribute this element specifies how the mosaicker determines which pixel to use as the output pixel. One method is better for images compressed losslessly and the other method is better for images that have been compressed lossily. The better method for images that were lossily compressed is pixelnontransparentfuzzy. The pixelnontransparentfuzzy method establishes a spherical zone of fuzziness around a given top pixel value (think of the R, G and B color values as values on the X, Y and Z axes of a three-dimensional graph). If the pixel value falls within that zone it is treated as the no-data value and will be transparent; that is, discarded in favor of the bottom pixel. This allows you to rope in those drifted no-data values. The pixelnontransparentfuzzy method requires the specification of a fuzziness value. For losslessly compressed images there is no danger of mistaking the no-data, since the pixel values remain bit-for-bit identical to those of the source image and thus cannot have drifted. In this case the BufferMergeRule element s method attribute should take the value pixelnontransparent. The top pixel is then always used unless it exactly matches the no-data value. The iserv-catalog-bands Property The latest version of the MrSID format, MrSID Generation 4 (MG4), supports multispectral (or multibanded ) imagery. Accordingly, Express Server supports multispectral MrSID images as source images. Express Server also supports multispectral source imagery in JPEG 2000 format. Selecting which bands to serve from multispectral images is called band mapping. To map bands you need only define a new catalog in the catalog configuration file and add a property to it called iserv-catalog-bands, then specify in a comma-delineated list which three bands (or which single band for grayscale) you d like to serve out from those available in the image. Here s an example: <Catalog name="cuprite_4_1_2"> <Provider name="file" root="cuprite" volume="/opt/lizardtech/sampleimages"/> <Property name="iserv-catalog-bands">4,1,2</property> </Catalog> In the above example, the iserv-catalog-bands property specifies that Express Server serves out the fourth band as band 1, the first band as band 2, and the second band as band 3. Express Server can serve different band combinations from the same images. For this, a new catalog is defined for each set of three bands (or single band) you would like to serve and the iserv-catalogbands property is used to specify which bands to use, as in the examples below. The first specifies a single infrared band (band 4 in this case), and the second specifies bands 5, 7, and 10. <Catalog name="cuprite_infrared"> <Provider name="file" root="cuprite" volume="/opt/lizardtech/sampleimages"/> <Property name="iserv-catalog-bands">4</property> </Catalog> <Catalog name="cuprite_5_7_10"> <Provider name="file" root="cuprite" volume="/opt/lizardtech/sampleimages"/> <Property name="iserv-catalog-bands">5,7,10</property> </Catalog> 14

19 A LizardTech White Paper If an image in a catalog cannot satisfy that catalog's band mapping a default band-mapping is applied, in which Express Server uses the first three bands if the image is RGB or multispectral and the first band if the image is grayscale. The wms-layer-list-srs Property The wms-layer-list-srs property can be included in any catalog that needs to be pulled into an application as a WMS layer in a coordinate reference system other than the default. This property specifies CRSs in a comma-separated list, which will be used to suggest alternative projections. Here is an example: <CatalogConfig> <Catalog name="foo" >... <Property name="wms-layer-list-srs">epsg:34522,epsg:53526</property>... </Catalog>... </CatalogConfig> Sample cat-cfg.xml File Following is a sample catalog from a catalog configuration file, where several properties and elements discussed above have been highlighted. <Catalog name="missouri_nir"> <Property name="iserv-catalog-bands">4,2,3</property> <Provider name="file" root="\lizardtech\expressserver7.0\sampleimages\geoeye" volume="c:"/> <Property name="wcs-publish-catalog-contents" value="true"/> <Property name="name">geoeye IR</Property> <Property name="credits">courtesy MJ Harden/GeoEye</Property> <Property name="description">this is the same dataset as "Missouri_RGB" but renders the NIR-G-B combination</property> <Property name="wms-layer-title"> <Title>GeoEye Missouri - IR</Title> </Property> <Property name="wms-layer-keywordlist"> <KeywordList> <Keyword>Missouri</Keyword> <Keyword>Geoeye</Keyword> <Keyword>IR</Keyword> <Keyword>satellite</Keyword> </KeywordList> </Property> <Property name="wms-layer-list-srs">epsg:2817,epsg:4326</property> <Property name="wms-layer-attribution"> <Attribution> <Title>Dataset provided courtesy MJHarden/GeoEye</Title> </Attribution> </Property> <BufferMergeRule fuzziness="3" method="pixelnontransparentfuzzy"/> <SpatialIndex classid="{d090dd8b-3d dc2cacdc3ea}"/> 15

20 How Express Server Software Improves Geospatial Image Delivery </Catalog THE JPIP CONFIGURATION FILE The JPIP configuration file controls how the server handles the connections that are requested: how many simultaneous connections to allow, how many threads to use, how fast to answer, how long to wait if the client is silent before terminating the session, what port to listen to, etc. Configuring the JPIP server is done by editing the parameters of the configuration files included with your installation. There are JPIP configuration files for both Windows and Unix platforms. The JPIP configuration file for Windows is an XML file called jpiphost.exe.config. The Unix version of the JPIP configuration file is called env.sh. The Unix configuration switches and their values are all stored on a single line separated by spaces. The most commonly edited portions of the JPIP configuration file are the array of strings in the RunServerCmdArgs setting. In the sample JPIP configuration file in the next section we ve highlighted a few items so that you can see that, for example: the port specified for JPIP transfer is 9013 <string>-port</string> <string>9013</string> the maximum size of the chunks served by this Express Server will be 8192 bytes <string>-max_chunk</string> <string>8192</string> a maximum of 1000 clients can be handled at one time <string>-clients</string> <string>1000</string> no client can be connected for longer than 100 minutes <string>-time</string> <string>6000</string> a maximum of 100 threads should be used in managing the establishment of new connections <string>-connection_threads</string> <string>100</string> Sample Windows JPIP Configuration File Following is a Windows JPIP configuration file very similar to the one that comes with your Express Server and sets the parameters for your JPIP server. <?xml version="1.0" encoding="utf-8"?> <configuration> <configsections> <sectiongroup name="applicationsettings" type="system.configuration.applicationsettingsgroup, System, Version= , Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="jpiphost.jpiplib" type="system.configuration.clientsettingssection, System, Version= , Culture=neutral, PublicKeyToken=b77a5c561934e089" requirepermission="false" /> </sectiongroup> 16

21 A LizardTech White Paper </configsections> <applicationsettings> <jpiphost.jpiplib> <setting name="runadmincmdargs" serializeas="xml"> <value> <ArrayOfString xmlns:xsi=" xmlns:xsd=" <string>requireddummyfirstarg</string> <string>host</string> <string>localhost:9013</string> <string>-passwd</string> <string>nottoocryptic</string> <string>-shutdown</string> </ArrayOfString> </value> </setting> <setting name="runservercmdargs" serializeas="xml"> <value> <ArrayOfString xmlns:xsi=" xmlns:xsd=" <string>requireddummyfirstarg</string> <string>-initial_timeout</string> <string>60</string> <string>-completion_timeout</string> <string>60</string> <string>-time</string> <string>6000</string> <string>-max_chunk</string> <string>8192</string> <string>-max_rate</string> <string>999999</string> <string>-port</string> <string>9013</string> <string>-catcfg</string> <string>auto</string> <string>-passwd</string> <string>nottoocryptic</string> <string>-wd</string> <string>_is_root_</string> <string>-log</string> <string>_is_root_\var\log\jpip.log</string> <string>-cd</string> <string>_is_root_\var\cache\jpip</string> <string>-clients</string> <string>1000</string> <string>-sources</string> <string>6000</string> <string>-connection_threads</string> <string>100</string> </ArrayOfString> </value> </setting> <setting name="logfilepath" serializeas="string"> <value>c:\lizardtech\expressserver\imageserver \var\log\jpipservice.log</value> </setting> </jpiphost.jpiplib> </applicationsettings> 17

22 How Express Server Software Improves Geospatial Image Delivery <system.diagnostics> <trace autoflush="true" indentsize="4"> </trace> </system.diagnostics> </configuration> PERFORMANCE Performance testing is done before the release of a new version of Express Server to ensure that in adding new features and fixing bugs no regression from earlier benchmarks has been incurred in terms of delivery speed. For the release of Express Server 7 internal tests were done to examine the difference in performance between Express Server 6 and Express Server 7. The following system was used: Dell PowerEdge 2850 Eight 2.80-GHz Intel Xeon CPUs 8 GB RAM Four 150-GB SATA 15,000 RPM HDDD in RAID 0 (stripe) Windows Server 2008 (32-bit) Apache 2.0 Imagery used was a 170,000 x 170,000 RGB dataset compressed at 20:1 (80 GB uncompressed) to MG3 and MG4 file formats. The imagery was compressed both as a single flat mosaic and as individual tiles that were mosaicked on the fly by Express Server. Client requests were issued from an application written in Perl that simulates a given test environment. No delay or sleep period was used in between requests so the test simulates users making requests immediately following the previous response. Each user issues 100 requests, which are randomly generated using a random zoom level and geographic location within the dataset for a chosen projection. Variables included scene sizes (256 x 256, 512 x 512 and 1024 x 1024), number of concurrent users (1, 5, and 15), output projection (the dataset s native projection and WGS84 Latlon EPSG: 4326) and output format (JPEG and PNG). One interesting result worth highlighting is that catalogs based on a single file respond much faster in Express Server 7 than they did with the previous version when under load. The graph below shows that for a flat MG3 mosaic in its native coordinate reference system a wait of almost 9 seconds is reduced to 4 seconds for 15 users and a wait of 6 seconds is reduced to less than 3 for five users in both cases a savings of greater than 50 percent. The reason for this is that in previous versions concurrent requests for the same source file were processed sequentially. Express Server 7 supports concurrent decodes from the same source image. 18

23 A LizardTech White Paper Figure 5: Flat MG3 Performance in Express Server 6 and 7 In nearly all test configurations, Express Server 7 proved as fast as or faster than its predecessor. The graph below showing the results for JPEG output will give you an idea of the kind of response times (in seconds) you might expect given a similar configuration. Figure 6: Performance of JPEG Output from MG3 in Express Server 6 and 7 CONCLUSIONS Express Server is a technologically advanced and efficient method of serving raster imagery that has been compressed to MrSID and JPEG 2000 format. Because it is designed to take advantage of the multiresolution nature of these formats and their support for selective decoding, Express Server used with other GIS image servers delivers imagery faster than those image servers can do alone, especially as the number of concurrent requests and size of imagery increase. 19

24 How Express Server Software Improves Geospatial Image Delivery Express Server s high configurability enables administrators to optimize performance and customize image catalogs according to customer needs. A few notable examples were given demonstrating the ways editable configuration files control various aspects of Express Server operation and performance. Because it supports standard protocols such as HTTP, JPIP, and WMS, Express Server enables organizations to deliver imagery quickly to users on any device, even in bandwidth-starved environments. As geospatial image data increases both in quality and in quantity, so user demand for access to that imagery will increase, especially now that applications with geospatial components are in the hands of millions of everyday phone users. Express Server is the fastest and most efficient method for ensuring that the imagery will be there whenever and wherever users need it. FURTHER READING For more information about LizardTech Express Server see the following: The Express Server product page at Express Server s online documentation at Case Study: Air Force Special Operations Command Case Study: State of New Jersey Office of Geographic Information Systems Case Study: Quebec Ministry of Sustainable Development, Environment and Parks For more information about Web Map Service (WMS) see the following: The WMS specification, available for download on the Open Geospatial Consortium (OGC) website: For information about JPIP see the following: JPEG 2000 Interactive Protocol (Part 9 JPIP) at The JPIP specification, available for download at the International Telecommunication Union (ITU) website: GLOSSARY Following is a list and definitions of several words, phrases and acronyms appearing in the foregoing text. alpha band also called alpha channel. An additional band used to contain masking or transparency information about other bands in an image. See also transparency. 20

25 A LizardTech White Paper API A language and message format used by an application program to communicate with the operating system, communications protocol or some other control program. band a set of samples corresponding to one spectral component of an image, e.g. the red band of an RGB image. base configuration file an XML file ( iserv-cfg.xml ) that instructs Express Server in how to cache image data and perform other basic functions. Bitmap a raster graphics image file format used to store bitmap digital images, independently of the display device (such as a graphics adapter), especially on Microsoft Windows and OS/2 operating systems. Also known as BMP. The BMP file format is capable of storing 2D digital images of arbitrary width, height, and resolution, both monochrome and color, in various color depths, and optionally with data compression, alpha channels, and color profiles. cache generally, a component that transparently stores data so that future requests for that data can be served faster. Express Server employs several cache strategies in concert for optimal performance. catalog an array of folders with images in them, located on one or more file systems to which Express Server has access. A catalog can also be a single indexed image. catalog configuration file an XML file ( cat-cfg.xml ) that defines the image catalogs and their properties. cat-cfg.xml file the name of the catalog configuration file. See catalog configuration file. client the viewing computer or application. More broadly, the requesting end of the spectrum in a request/supply relationship between programs. composite mosaic a compressed MrSID mosaic in which all the input tiles remain individual images wrapped by a single file structure. Unlike in a flat mosaic, which becomes a single image upon encoding, any image in a composite mosaic can be updated in place. See also flat mosaic and mosaic. compression an operation that creates a new image file from an original image file such that the file size of the new image is smaller. The reduction in file size may be at the expense of some image quality. (Note that the file size is what is reduced, not the dimensions of the image itself.) See also lossless and lossy. coordinate reference system (also referred to as CRS, projection, spatial reference system, SRS), a coordinate-based local, regional or global system used to locate geographical entities. A coordinate reference system defines a specific map projection, as well as transformations between different coordinate reference systems. Coordinate reference systems are defined by the OGC's Simple feature access using well-known text, and support has been implemented by several standards-based geographic information systems. Coordinate reference systems can be referred to using a SRID integer, including EPSG codes defined by the International Association of Oil and Gas Producers. CRS See coordinate reference system. 21