23
Sep
2016
Author: Brian Griglak
Since the early days of ENVITasks in ENVI 5.2, there has been what we call the Dynamic UI. Some of the toolbox items that wrap ENVITasks use it, but you can use it at any time to set some or all of the parameters of your task using the ENVIUI::SelectTaskParameters() method. When you call this method, it will inspect the task to get the NAME, TYPE, and VALUE properties of each parameter, and construct a dialog with widgets for each. If the VALUE is !NULL, then the widget will be empty, but if it has a valid value the widget will display that. We have a set of heuristics that try to select the best widget to use for each TYPE, but it may not choose the widget you desire for a particular parameter.
To address this, we are introducing task style sheets in the upcoming release of ENVI 5.4. The idea is borrowed from HTML and CSS, which separate content from presentation. In the ENVITask context, the ENVITask template defines the content, and the style sheet defines the presentation logic. These style sheets are nowhere as sophisticated as CSS can be, starting with the lack of cascading, but they don’t need to be for our purposes. The style sheet is a JSON file or in-memory Hash that allows you to hide a couple of the widgets at the bottom of the dialog, and specify which widget to use for each parameter. You don’t need to specify every parameter, those that are not in the style sheet will fall back to the heuristics.
Let’s make this concrete using the example from the help page:
e = ENVI() Task = ENVITask('NNDiffusePanSharpening') ret = e.UI.SelectTaskParameters(Task)
The resulting pop-up dialog looks like this:
The “Pixel Size Ratio” parameter has to be an integer, so we used the edit widget with the increment/decrement buttons next to it. But maybe you want to use a wheel instead; this is where a style sheet comes into play.
I can change the “Pixel Size Ratio” parameter to use a wheel widget, like this:
style = Hash("schema", "envitask_3.0", $ "parameters", List(Hash("name", "pixel_size_ratio", $ "type", "IDLWheel_UI"))) ret = e.UI.SelectTaskParameters(Task, STYLE_SHEET=style)
One key point is that the “parameters” value must be a List of Hashes, even for a single parameter. The equivalent JSON file is this:
{ "schema": "envitask_3.0", "parameters": [ { "name": "pixel_size_ratio", "type": "IDLWheel_UI" } ] }
The dialog now looks like this:
All of the possible values for “type” are well documented, under the heading “User Interface Elements”. Some of the widgets allow you to specify extra properties to customize the behavior. The IDLWheel_UI class, for example, supports specification of MIN and MAX properties. If the parameter has these properties set, they will be used, but as you can see in the case of NNDifusePanSharpening it doesn’t. But we can specify them in the style sheet if we want to add them. We do this by putting all these properties into a Hash under the key “keywords”:
style = Hash("schema", "envitask_3.0", $ "parameters", List(Hash("name", "pixel_size_ratio", $ "type", "IDLWheel_UI", $ "keywords", Hash("min", 1, $ "max", 9)))) ret = e.UI.SelectTaskParameters(Task, STYLE_SHEET=style)
The equivalent JSON file is this:
{ "schema": "envitask_3.0", "parameters": [ { "name": "pixel_size_ratio", "type": "IDLWheel_UI", "keywords": { "max": 9, "min": 1 } } ] }
In all the examples, I have manually specified the STYLE_SHEET keyword in the call to SelectTaskParameters(). If you want the style sheet to be automatically used any time you call this method with your task, then create the JSON file named <task name>.style and put it in the same folder as the .task file.
Categories: IDL Blog | IDL Data Point
Tags:
20
Author: Jason Wolfe
In this article I will show an example of how you can improve the accuracy of a supervised classification by considering different attributes.
Supervised classification typically involves a multi-band image and ground-truth data for training. The classification is thus restricted to spectral information only; for example, radiance or reflectance values in various wavelengths. However, adding different types of data to the source image gives a classifier more information to consider when assigning pixels to classes.
Attributes are unique characteristics that can help distinguish between different objects in an image. Examples include elevation, texture, and saturation. In ENVI you can create a georeferenced layer stack image where each band is a separate attribute. Then you can classify the attribute image using training data.
Creating an attribute image is an example of data fusion in remote sensing. This is the process of combining data from multiple sources to produce a dataset that contains more detailed information than each of the individual sources.
Think about what attributes will best distinguish between the different classes. Spectral indices are easy to create and can help identify different features. Vegetation indices are a good addition to an attribute image if different vegetation types will be classified.
Here are some other attributes to experiment with:
Including elevation data with your source imagery helps to identify features with noticeable height such as buildings and trees. If point clouds are available for the study area, you can use ENVI LiDAR to create digital surface model (DSM) and digital elevation model (DEM) images. Use Band Math to subtract the DEM from the DSM to create a height image, where pixels represent absolute heights in meters. In the following example, the brightest pixels represent trees. You can also see building outlines.
Example height image at 1-meter spatial resolution
Locating coincident point cloud data for your study area (preferably around the same date) can be a challenge. Luckily I found the perfect set of coincident data for a classification experiment.
The National Ecological Observatory Network (NEON) provides field measurements and airborne remote sensing datasets for terrestrial and aquatic study sites throughout the world. Their Airborne Observation Platform (AOP) carries an imaging spectrometer with 428 narrow spectral bands extending from 380 to 2510 nanometers with a spectral sampling of 5 nanometers. Also onboard is a full-waveform LiDAR sensor and a high-resolution red/green/blue (RGB) camera. For a given observation site, the hyperspectral data, LiDAR data, and high-resolution orthophotography are available for the same sampling period.
I acquired a sample of NEON data near Grand Junction, Colorado from July 2013. My goal was to create an urban land-use classification map using an attribute image and training data. For experimentation and to reduce processing time, I only extracted the RGB and near-infrared bands from the hyperspectral dataset and created a multispectral image with these bands. I used ENVI LiDAR to extract a DEM and DSM from the point clouds. Then I created a height image whose pixels lined up exactly with the multispectral image.
I created an Enhanced Vegetation Index (EVI) image using the Spectral Indices tool. Finally, I combined the RGB/NIR images, the relative height image, and the EVI image into a single attribute image using the Layer Stacking tool.
Next, I used the Region of Interest (ROI) tool to collect samples of pixels from the multispectral image that I knew represented five dominant classes in the scene: Water, Asphalt, Concrete, Grass, and Trees. I used a NEON orthophoto to help verify the different land-cover types.
I ran seven different supervised classifiers with the multispectral image, then again with the attribute image. Here are some examples of Maximum Likelihood classifier results:
Maximum Likelihood classification result from the NEON multispectral image
Notice how the classifier assigned some Building pixels to Asphalt throughout the image.
Here is an improved result using the attribute image. Those pixels are correctly classified as Building now.
Maximum Likelihood classification result using the attribute image
A confusion matrix and accuracy metrics can help verify the accuracy of the classification.
Confusion matrix calculated from the attribute image classification
The following table shows how the Overall Accuracy value is higher with the attribute image when using different supervised classifiers:
The accuracy of a supervised classification depends on the quality of your training data as well as a good selection of attributes. In some cases, too many attributes added to a multispectral image can make the classification result worse, so you should experiment with what works best for your study area. Also, some classifiers work better than others when considering different spatial and spectral attributes. Finally, you may need to normalize the different data layers in the attribute image if their pixel values have a wide variation.
New tutorials will be available in ENVI 5.4 for creating attribute images and for defining training data for supervised classification.
National Ecological Observatory Network. 2016. Data accessed on 28 July 2016. Available on-line at http://www.neonscience.org from National Ecological Observatory Network, Boulder, CO, USA.
Categories: ENVI Blog | Imagery Speaks
13
Author: Albert Spratley
The rapid growth of unmanned aerial vehicles (UAVs) and payloads has resulted in an ever growing deluge of data that has to be archived, sorted, analyzed, and distributed to consumers across the defense, agriculture, and utility markets. In many cases, especially in the case of full motion video (FMV), a single flight can result in several hours of data that has to be viewed and analyzed. Often only a small fraction of that data is useful for analysis purposes. For larger UAV fleets, with multiple, simultaneous missions, substantial resources are required to perform the analysis. The resources required to analyze these data products increases cost proportionally to the amount of data collected.
For systems that have adopted the use of properly formatted metadata, we can attempt to filter this glut of data by analyzing patterns and attempting to infer some operator intent based on domain knowledge. For example, identifying temporal “pauses” for the sensor center field of view may indicate an area or point of interest for further analysis. Circular patterns in the sensor center field of view could indicate the inspection of a building, object, or structure of significance. Smooth “pans” during the video or “sweeping” motions across the ground can infer a collection aimed at covering an area on the ground.
Harris Geospatial Solutions has designed and prototyped algorithms capable of identifying these useful segments of video by analyzing the metadata embedded within the video stream. These “passive analytics” run in real time, during the UAV flight, and identify sub-sections of video that are far more likely to be useful in a more detailed analysis. By dynamically detecting, and setting aside these sub-clips of video, the burden of first-phase analysis can be greatly reduced, allowing the user to focus their analytical and dissemination resources on meeting the challenges of their market space rather than wading through a sea of irrelevant data.
1
Author: Jim Pendleton
First, a dose of nostalgia.
In the early days of commercial IDL, new drops of the application occurred when new features were added and as bugs were fixed for important customers. It was not unusual for there to be a couple different releases per month, a release cycle concept not dissimilar to that of most of today's smart phone apps.
The new releases were signaled through an update to a README-type of text file that was available on a node on a computer network called DECNET, shared by many universities and national labs in the days before the internet as we know it today.
At the organization where I worked, I had a nightly batch job that would alert me to the availability of a new version of IDL. It was a highlight of my week when new features appeared in IDL. Yes, I had that sort of a life back then. Frequent updates, from a customer point of view, kept the buzz alive with the products.
Here we are about 30 years later and this functionality to check for updates is now built into the upcoming releases of both IDL 8.6 and ENVI 5.4. By default, IDL will check once a week automatically for updates when a new session is started.
Additionally, with the click of a single "Help/Check for Updates..." menu button in the IDL Workbench or from the ENVI UI, you can ensure that you, too, are enjoying the freshest and best we have to offer.
If your version is current, you will receive a dialog assuring you all is well.
To check that your ENVI version is current, find the menu item in the main application user interface.
You will need an internet connection to the commercial world for the status check to complete successfully.
Extra "80s-throwback" credit if you use a packet sniffer to find the syntax of the request and write a script that will automatically launch a WGET query each time you start a new IDL session.
Does this new feature signal a return to more frequent application updates? Have we gone back to the future? Only time will tell.
28
Aug
Author: Atle Borsholm
Bi-linear interpolation
Lanczos resampling
Lagrange resampling
Base 60 encoding of positive floating point numbers in IDL
First Valley Shadow Detection
Machine Learning Training for Automatic Target Detection
Sign Up for News & Updates: Stay informed with the latest news, events, technologies and special offers.