Monday, April 28, 2008

Heading to Portland, Whereyougonnabe?

Later today I'll be traveling to Portland for the annual ASPRS Conference. The theme of the conference, "Bridging the Horizons - New Frontiers in Geospatial Collaboration", got me thinking about the new (beta) Facebook application called Whereyougonnabe? from Peter Batty and co at Spatial Networking. Whereyougonnabe is a service that allows you to enter in the "where and when" of upcoming trips and activities. The application then lets you know which of your friends will be close to you, making it handy for all kinds of reasons. This sheds some light on the company name: spatial instead of social in "Spatial Networking". I had a chance to play around with it a bit recently and was particularly impressed with the Google Earth support. The application allows you to click on a link that generates a KML file that you can use to fire up Google Earth (and other KML-supporting apps) and view your (and your friend's) trip pathes. See the screenshot below for my trip to Portland:


Not only is your path displayed, but it also has a timeline control. It also generates an icon out of your profile picture, which is useful as well.

Back to ASPRS: I will write some updates throughout the week, but if you happen to be going think about stopping by our UGM tomorrow morning, or come by the booth anytime! We'll be giving out some new ERDAS t-shirts and will also be have a draw for an Iphone between 3 and 4pm on Wednesday.

Saturday, April 26, 2008

Dodging: Intro and Statistics

One of the problems with creating seamless image mosaics or tiled orthophotos is "getting the radiometry right". What does that mean? Well, there are a lot of things that can turn a project sour when trying to make a good-looking final product. Some common radiometric issues are:

  • Hotspots and vignetting: these are common in scanned aerial photography, where the sun's reflection causes a bright spots. Vignetting is where a darkening occurs towards the corners of the image. See here for a good vignetting description.
  • Flightlines of imagery flown on different days or different times of the day. Some mosaicking jobs include images that were flown at either different times of the day, or on different days (with different weather conditions). This can be a difficult problem to deal with because the imagery of the adjoining flightlines may be completely different in terms of the sun angle, brightness level, cloud coverage, and so forth.
  • Brightness problems. Another issue is when, usually due to on-board sensor settings, one color band's brightness level is either too high or too low. For example, the imagery looks "blue-ish" because the blue band brightness level is skewed. Panchromatic imagery may also be too dark or light and need adjustment. It is also possible for there to be brightness variation within on image.
See the image below for an example. Three of the corners are dark and the bottom of the scene is inconsistently light compared to the rest of the scene. Overall the radiometry is uneven.

For aerial photography, one tool that can be used to alleviate the above problems is a process known as dodging. While there may be other problems, such as atmospheric issues associated with satellite imagery, these may require the use of other tools.

So how can dodging help?

Dodging basically attempts to create a uniform spectral intensity within and across images. Dodging, in the traditional photography sense of the word, is about reducing the exposure in a portion of the image in order to make that portion appear lighter. In photogrammetric processing this completely digital process. There are numerous programs available to perform dodging, and they often share techniques.

From ERDAS we offer dodging capabilities in a few different applications, namely Leica MosaicPro and ImageEqualizer. Both of these applications use a dodging algorithm originally developed by LH Systems for use with the DSW scanner line (implemented in a program called Fastdodge).

In these applications, the processes for statistics generation are similar:

A set of statistics are calculated (e.g. mean, standard deviation), which are based on certain user-defined parameters. These include grid size, skip percentage, and the minification layer (aka pyramid layer) for the process to run on. Of these, both the grid size and minification layer can be quite critical for success.
    1. Grid size defines the number of grid tiles in x and y for statistics to run on. For example, a grid size of 10 will result in 100 grid tiles (10 in x, 10 in y). Depending on the scene, this can have a big affect. For example, frames with relatively contiguous radiometry can use small grid sizes. "Complex" scenes, such as a frame containing water, urban, and rural/vegatated areas, usually require a higher grid size/density to prevent one radiometrically contiguous area from affecting another area. For example, consider a patch of dark green vegetation surrounded by say, lighter colored grain crops. If the grid size is significantly larger than the dark green patch, the output (depending on the constraints applied) will wash out the dark green because of the statistical influence of the DN values of the lighter colored grains. However, sometimes the problem outlined in this example can be impossible to avoid! This is why dodging is both an science and an art....
    2. "Skip percentage" is generally referred to as an "edge trimmer" (e.g. the percentage of the image edge that will be ignored during stats generation). It is important not to confuse this with "skip factor", which generally refers to a certain factor of pixels to "skip" when calculating stats. Using a high skip factor can have the same effect as using a lower-resolution pyramid layer.
The "minification" (or pyramid layer) setting is used to define which minification layer (e.g. a reduced resolution version of the 1:1 image) to use for stats calculation. Using a lower-resolution minification layer will result in faster stats generation, but it needs to be used with caution because if you have a radiometrically-complex (e.g. lots of non-contiguous radiometry, or in other words a "busy" scene) using a low-res minification layer can skew the stats.

Wednesday, April 23, 2008

Sensor Spotlight: the RC30

Since I covered a satellite sensor in the last sensor spotlight, I thought I would go for a airborne sensor this time. The focus of today's post is the RC30, which has been the workhorse of the airborne mapping community for many years. Introduced in 1992 by Leica Geosystems, over 400 cameras have been deployed all over the world.

About the sensor: the RC30 is a frame camera system that can capture imagery in color, panchromatic, and false color film. There are a couple of different lens options (6 and 12 inch focal lengths), which allow for large-scale mapping applications. Complete specifications are available here.

For an example of what RC30 imagery looks like, check out the orthophotos available online at MassGIS. These were flown by Keystone Aerial Surveys, who also happen to have a great photo of the camera on their site here. Other components in the system may include a GPS/IMU system, a PAV30 gyro-stabilized mount, a GPS reference station, and more.

In LPS, the workflow for the RC30 is the classical frame photogrammetry workflow - it is basically the workflow outlined here.

Lastly, just to demonstrate the longevity of this sytem, check out this advertisement from 1988 for an RC20 (Wild Heerbrugg was an earlier incarnation of Leica Geosystems). The RC20 was the predecessor to the RC30, and is essentially the same except for the addition of gyro-stabilized suspension on the RC30. Aside from that, I just think it is a very cool ad!!!

Triangulated Irregular Network (TIN) Formats and Terrain Processing

One issue in the mapping community is that there is no standard format for Triangulated Irregular Network (TIN) terrain files. Most geospatial applications use proprietary formats, which presents serious interchange problems when moving the data around (e.g. from clients to customers, or even within an organization). Unfortunately we are guilty of this as well in LPS, with our LTF TIN format. Many people get around the limitations of proprietary formats by using ASCII as a common interchange format, where the TIN mass points are listed in XYZ for each row (separated by commas, tabs, or whitespace). Some systems also support the notion of points codes for breaklines, which are a critical part of the TIN structure. The main problem with ASCII is that once you get over several million points, the file can be cumbersome to deal with - which means it may be necessary to divide up the data into tiles. Alternatively you can convert the TIN to a raster format, but this can be undesirable if you have dense mass or unevenly distributed points, or if you have breaklines in the TIN (since rasters don't support breaklines).

A case in point is the LIDAR data from the Washington State Geospatial Data Archive. While there are standards for LIDAR data, most commercial applications do not (yet) natively support it. Hence there is a need to make the data available in alternate formats. The data is available in ASCII and TIN format for each quarter quad, but the TIN format is in .e00 format, which is an old interchange format developed by ESRI. Hence, the site recommends Importing the .e00 files into ArcMap in order to use them. The only issue with that is that you need ArcMap... This is likely a reason for including XYZ ASCII as an option as well. Another option is a 3 meter DEM for the entire coverage area, which is possible to download from here. It is in Arc/Info binary grid format though...

So how do we handle all of this in LPS?

There are a few different options here, and the LPS and IMAGINE groups have been working on a solution. Prior to the LPS/IMAGINE 9.2 release, users had to either use the 3D Surface Tool in IMAGINE or the terrain Split and Merge tool in LPS Core. In 9.2, and moving forward in future releases, we are consolidating our efforts by extending the LPS Split and Merge tool and making it available in IMAGINE, which we have renamed to the "Terrain Prep Tool". It is available in Data Prep > Create Surface in IMAGINE, or from Tools > Terrain Prep Tool in the LPS Project Manager.
The Terrain Prep Tool adds new split/merge functionality inherited from LPS as well as resolving some longstanding limitations associated with the 3D Surface Tool (e.g. it dramatically increases the number of points that can be handled). For 9.2 we also added a few formats such as LAS and two flavors of ASCII (with and without point codes for breaklines). The 3D Surface Tool will likely remain available for a few more versions, until we have fully replaced it's functionality in the Terrain Prep Tool.

Friday, April 18, 2008

3D City Building Case Study

While high-fidelity 3D city models have been around for 10+ years, they have been getting a lot of attention in recent years with the advent of Google Earth and Virtual Earth. I've touched a little bit on 3D building extraction and texturing in a previous post, but recently came across an excellent case study from Magnasoft entitled "Build Virtual Cities to Plan Real Cities".

The case study provides an overview of start to finish textured city construction. The main input data consists of stereo pairs, and the software involved includes LPS, MicroStation, and ArcGIS. The final products go well beyond just buildings: they also include roads, tree canopies, water bodies, electric poles, walls, and fences. You can see from the stereo feature compilation screen shot (on part 5) that complex building structures can be modeled in high detail.

Just to explain the process in a bit more detail: MicroStation is important because LPS' main 3D feature extraction application, PRO600, is an MDL application that hooks in the LPS stereo viewer and allows users to extract 3D objects in stereo within the MicroStation environment. After the building intelligence is added in ArcGIS, the models are brought into Stereo Analyst for IMAGINE (another 3D extraction tool, which is an add-on to ERDAS IMAGINE), where a feature called the Texel Mapper can be used to automatically texture the buildings from the "block" of aerial photographs. I'll expand more on this process in a future post...

Wednesday, April 16, 2008

Service Pack 1 for LPS and ERDAS IMAGINE 9.2 Now Available!

The new service pack for LPS and IMAGINE is now available for download on the ERDAS Support Site. Instead of releasing separate service packs for LPS and ERDAS IMAGINE, we decided to release a single consolidated SP that covers both products, which should make life easier for users.

While the SP mainly consists of fixes, we have some new features in LPS that I wanted to highlight as well. One of the main new features is the Post Editor in the Terrain Editor. This tool (see the screenshot below) is for gridded terrain data, and allows you to quickly jump from post to post, adjusting the Z value as you go. The navigation is also device-mappable, so you can use keyboard shortcuts or buttons on an input device (e.g. a Topomouse).Also of note is that we have extended the "Adaptive ATE" option to work with all supported sensor models, as it previously just worked for frame and ADS40 data. We were able to see some good improvements for several satellite sensors we tested with.

Here is a complete list of the fixes and enhancements:

LPS

· Automatic Terrain Extraction (ATE):

o Added note to online help for Adaptive ATE explaining that image datasets vary and you must check your results and make selections (both the method and the ATE parameters) based on your particular datasets. [LPS-1626]

o Adaptive ATE correctly generates DTMs using ADS40 images and does not show the error message "failed to transform points". [LPS-1531]

o Resolved a "Bad allocation" memory error when using ADS40 images to generate a DTM in .img format. [LPS-1540]

o Added note to OLH advising user about using pyramid levels and effective building filtering. [LPS-1582]

o Adaptive ATE now measures points over the complete stereo model area; not just 70 to 80% (center part). [LPS-1482]

o Fixed DTM extraction "out of space" error so that the user can cancel the process. [LPS-1548]

o Fixed an ATE issue associated with the "individual files" output setting. [LPS-1313]

o Added support for all sensors in Adaptive ATE (not just frame cameras and ADS sensors). [LPS-1562]

· Block Triangulation:

o Synchronized units of measure for GCPs and residuals in Refinement Report. [LPS-1267]

· Documentation:

o Added tip to Mosaic OLH explaining how to correctly lay out ADS L2 images. [LPS-231]

o Enhanced content for "Set Constant Z" in Terrain Editor OLH. [LPS-1341]

o Updated OLH hyperlink in Camera File Info. [LPS-1508]

o Improved the content of the View Manager OLH. [LPS-1465]

· Terrain Prep:

o Eliminated write permission errors when opening LTF files. [LPS-1187]

· Frame Editor:

o Eliminated LPS blockfile issues when editing the model parameters in Frame Editor for the WorldView Orbital Pushbroom and SPOT5 models. [LPS-1545]

o "Cancel" option cancels current image in the Frame Editor and not the selected image in the LPS project manager cellarray. [LPS-1577]

· Interior Orientation:

o Changing the camera selection for a block file (after performing IO with the wrong camera) no longer prevents subsequent IO with the same block file and the new camera selection. [LPS-1283]

· LPS General:

o Synchronized units of measure for the Average Flying Height (Frame Camera) and Average Elevation (Orbital Pushbroom) in Block Property Setup with the units in the block file. [LPS-1575]

o New Feature: Stereo Analyst - "Extend Features to Ground", which uses a 3D Polygon Shapefile and extends the segments of each polygon (as faces) to the ground to form solid features (e.g. Buildings). [LPS-1567]

o The Average Elevation, Minimum Elevation and Maximum Elevation units in RPC Model projects are now displayed in the project vertical units in the Frame Editor [LPS-1597]

o Eliminated write permission errors when opening LTF files. (See LPS-1187) [LPS-1492]

o Added QuickBird/WorldView NCDRD format support to online help. [LPS-1610]

o Added support for the Latvian Gravimetric Geoid (LGG98) and Latvian Coordinate System (LKS-92) [LPS-1557]

o Added support for the LHN95 geoid (Switzerland). [LPS-1556]

· MosaicPro:

o Fixed MosaicPro occasional issues when running Image Dodging with default settings on tiled TIFF images. [LPS-1554]

o Improved performance for seam polygon generation with "most nadir", "geometry", and "weighted" options. [LPS-1552]

o Fixed occasional display issue when one or more images have been mosaicked but do not display. [LPS-1578]

o Fixed MosaicPro occasional issues when working with pyramid layers (Image Dodging and Mosaicking). [LPS-1553]

o Resolved an issue associated with clipping Shapefiles that do not contain projection information. [LPS-585]

· Orthoresampling Process:

o Resolved an issue associated with orthophoto generation when using ATE-derived LTF files in LSR coordinate systems. [LPS-1579]

· Import/Export:

o Enhanced Importer for ISAT projects with multiple flight lines. [LPS-1550]

· Sensor Models:

o In special cases where the RPC does not have a change in the Z value, Triangulation failed with an error of "error with computing default ground delta". These special cases now triangulate correctly. [LPS-1510]

o Added support for NITF NCDRD format in orbital pushbroom QuickBird/WorldView model. [LPS-1551]

· Terrain Editor:

o New Feature: Post Editor (Terrain Editor) - allows a user to quickly move through points and adjust the Z value for selected points in grid terrain files. [LPS-484]

o Enhanced jpeg image display quality in Terrain Editor. [LPS-1547]

Leica Stereo Analyst

· Stereo Analyst:

o Extend Features to Ground will convert flat 3D polygons into solid shapes by extruding each polygon to the ground. Ground elevation may be defined by Shape Attributes, Terrain Dataset or a constant height. Output may be directed to a Multipatch Shape File or 3DS file. [SAI-136]


ERDAS IMAGINE

· Classification:

o Added subpixel demo example files which were missing in ERDAS IMAGINE 9.2 [IMG-3326]

· Data Exchange:

o Improved MrSID MG2 and MG3 map projection support by allowing the population of internal WKT strings and writing external PRJ files. [IMG-3148]

o Improved MrSID reading support by implementing reading of MrSID World Files and ESRI Projection Files. [IMG-1107]

o Improved portability of 1-bit TIFF images for use with software products outside of ERDAS IMAGINE. [IMG-1709]

o Corrected error in MrSID file creation that caused problems in Microstation sofware. [IMG-1342]

o A correction for the stagger phenomenon was implemented for AVNIR-2 level 1A/1B1 data. [IMG-3019]

o Expanded ECWs supported projection and map units. [IMG-2540]

o Enhanced Oracle GeoRaster compatibility. [IMG-3229]

· Data Prep:

o Added support for Imagizer Data Prep for Windows Vista. Requires the customer to install the Windows Vista Support Update in conjunction with this fix to take advantage of this feature. [IMG-3029]

o Added non-linear surface creation option to Terrain Prep Tool. [IMG-3286]

o Improved performance of 2D shapefiles with attribute defining elevation in Terrain Prep Tool. [IMG-3313]

· Geospatial Light Table (GLT):

o Improved GLT scale display accuracy, when rotating imagery with rectangular pixels. [IMG-2324]

· ERDAS IMAGINE General:

o Updated the setting of the IREP NITF flag when chipping DTED so they would display correctly. [IMG-2311]

o Enhanced toolkit API: CloseMeasure("nosave") will no longer ask to save the measurements, CloseMeasure() will ask to save measurements. [IMG-2885]

o Add support for Dutch RD projection to ERDAS IMAGINE 9.2. [IMG-2976]

o Improved reliability of Toolkit callback functions [IMG-3284]

o Added support for WorldView RPC in Warptool & AutoSync [IMG-3369]

· Interpreter:

o Introduced a new resolution merge capability, the Subtractive Resolution Merge. [IMG-3295]

· NITF Import/Export:

o Fixes a problem creating JPEG 2000 compressed NITF files that were smaller then 1024x1024 pixels. [IMG-3366]

· Vector:

o Added "Use White Textbox" option to Attribute to Annotation tool. [IMG-3218]

· Viewer:

o Removed the Render outside of View preference in the Viewer Preferences. This feature is no longer needed with today's viewing technology and when on slows down viewing speed. [IMG-3252]

o Corrected the detection of pyramid layers for NITF images with external pyramid layers in support of Dynamic Range Adjustment (DRA). [IMG-2864]

o Fixed IEE functionality. [IMG-3044]

ERDAS IMAGINE Add-ons

· AutoSync:

o Improved the AutoSync Resample Setting Clip to Reference Image Boundary option to more closely clip to the reference image boundary. [IMA-483]

· Radar Mapping Suite:

o Improved support for complex TerraSAR-X (type SSC) data. [IMA-539]

Saturday, April 12, 2008

Sensor Spotlight: ALOS Prism

While there is a lot of interest in "high resolution satellite/airborne data" out there in the blogosphere, I haven't seen much discussion on the merits of individual sensors. Hence, I thought it would be interesting to focus a post now and then on individual satellite and airborne sensors.

One satellite sensor that has been getting a lot of attention lately is ALOS PRISM (Panchromatic Remote-sensing Instrument for Stereo Mapping). ALOS was launched on January 24th, 2006 from the Tanegashima Space Center in Japan. While the focus of this post is on the PRISM sensor, the satellite also hosts two other on-board sensors: the AVNIR-2 and PALSAR sensors.

The unique aspect of the PRISM sensor is that it has it is a pushbroom sensor, with three optical systems for capturing forward, nadir, and backward imagery. At nadir the spatial resolution is 2.5 meters. The complete specs are here. For stereo photogrammetry applications, the key factoid about PRISM is that it collects stereo imagery, so it is possible to extract 3D terrain and feature information.

RESTEC, the Remote Sensing Technology Center of Japan, also has a wealth of information on ALOS and ALOS PRISM. In addition to all the background information, it also has some useful sample data. Here is a sample PRISM image. RESTEC has also developed an ALOS Viewer application that can be used to open images from the various ALOS sensors and perform basic operations like measuring distance and, in the case of stereo PRISM data, manually measuring building height.

Lastly, one thing to note is the the ALOS PRISM rigorous sensor model is supported in LPS 9.2. If this is a data type you need, please look into getting your hands on the new version!