Author: Thomas Harris
Every December I look forward to the AGU Fall Meeting in San Francisco. It's always an amazing time, visiting the great city of San Francisco with more than 22,000 like-minded geo-science geeks.
This year, I'll be attending the 2013 AGU Fall Meeting with David Hulslander. Both Dave and myself will be presenting some of our recent work at Exelis and seeking opportunities to interact with all the geo-scientists that use IDL and ENVI in their work.
If you're going to AGU, please stop by one of our posters or talks, or, send us a note on Twitter to schedule a meet-up.
On Monday (8:00am-12:20pm |ED11B-0745), December 9th, we'll be presenting 'Academic and Non-Profit Accessibility to Commercial Remote Sensing Software' that gives great background on Exelis support of academic programs like NASA DEVELOP. Exelis is committed to supporting the academic and NGO communities, so if you need access to remote sensing and geospatial software tools, please stop by to speak with us.
Also on Monday (1:40pm-6:00pm| EP13A-0836), David Hulslander will be presenting some of his work on comparing relative bathymetry derived across Landsats 5, 7, and 8, showing how improvements in the Landsat imaging sensors are leading to better analytical results.
On Tuesday (1:40am-6:00pm| IN13A-1408), find me at my poster where I'll be presenting some work spearheaded by Rahul Ramachandran and Manil Maskey at University of Alabama Huntsville on cloud-based collaborative scientific programming environments. This work is exciting because it empowers scientist to collaborate virtually on big-data processing jobs (and it uses cloud-based IDL and ENVI).
Finally, on Friday (11:05am-11:20am | IN52A-04), I'll be presenting a talk on exciting technology we've been applying to solve tough computational planetary science problems, 'Using Graphical Processing Units to Accelerate Orthorectification, Atmospheric Correction, and Transformations for Big Data'.
Categories: IDL Data Point
Tags: IDL, ENVI, EDU, AGU, Orthorectification, environmental monitoring
Author: Mark Piper
For example, let's say I have the following program:
print, a ; #fail
When called, THROW_ERROR will fail at the PRINT statement
because you can't print an undefined variable in IDL:
% PRINT: Variable is undefined: A.
% Execution halted at: THROW_ERROR 4 C:\Users\mpiper\blog\posts\20130823-get-last-er
You can see that IDL gives you the file and line in the file
where the error occurred. But how can we get this programmatically?
Unfortunately, this information isn't included in !ERROR_STATE, the system variable that contains information on the last error
that occurred, and also the place where I'd expect to find this
information. Luckily, there a couple ways to get it. Here's one:
use HELP with the LAST_MESSAGE and OUTPUT keywords:
IDL> help, /last_message, output=err_txt
IDL> help, err_txt
ERR_TXT STRING = Array
IDL> print, err_txt
% PRINT: Variable is undefined: A.
% Execution halted at: THROW_ERROR 4 C:\Users\mpiper\blog\posts\20130823-get-last-error-message\throw_error.pro
This is a little sloppy, but you can now use string processing routines to parse the error information out of the
Carmen Lucas, a scientist at DRDC Atlantic in Dartmouth, NS, created this visualization with IDL:
(click to embiggen)
Carmen explains that this is:
... the magnetic scalar potential surface and contour, and associated magnetic flux density vector field B. Note the flux density field getting "pumped" uphill inside the two magnets as shown on the surface plot.
It's been awhile since I've shown a cool visualization made with IDL, so thank you, Carmen, for sharing this!
Tags: (New) Graphics, IDL 8
I'm a little embarrassed about this, but last week I
learned (or maybe "recalled" is more accurate) that you can
create multi-record GRIB files using only the
command. For example, with files a.grb
and b.grb, I can make a new file c.grb
$ cat a.grb b.grb > c.grb
To perform the equivalent action solely within IDL, read the
files as a bytestream, concatenate the data, then write the data back
as a bytestream; e.g.:
IDL> a = read_binary('a.grb')
IDL> b = read_binary('b.grb')
IDL> c = [a, b]
IDL> openw, u, 'c.grb', /get_lun
IDL> writeu, u, c
IDL> free_lun, u
That's it. What do you think?
Actually, while writing this, I thought of a pair of feature requests.
Today I'd like to show something I encountered recently that's
not terribly important, but that I found interesting.
In IDL 8 (a.k.a. New) Graphics, the RGB_TABLE property can take
as input a color table index, an integer on 0-74. Internally,
the color information is converted to a color table array, a 3 x
256 byte array. For example, here I display a distance map (with
function) as an image with color table 70:
IDL> g = image(dist(400), rgb_table=70)
When I retrieve the color table, it's been converted into a
color table array:
IDL> help, g.rgb_table
<Expression> BYTE = Array[3, 256]
What if I'd like to get back the color table index, 70? Here's a
program that attempts to solve this problem:
; docformat = 'rst'
; Attempts to determine which built-in color table matches an input [256,3]
; or [3,256] array of colors.
; rgb_table: in, required, type=byte
; A [256,3] or [3,256] byte array of color table values.
; The color table index if matched, else the input is passed through unchanged.
; IDL 8.2.1
; Mark Piper, VIS, 2013
function determine_colortable, rgb_table
compile_opt idl2, hidden
do_transpose = (size(rgb_table, /dimensions)) eq 3
!null = colortable(get_names=all_ct_names)
for ct_index=0, n_elements(all_ct_names)-1 do begin
ct_array = colortable(ct_index, transpose=do_transpose)
if array_equal(rgb_table, ct_array) then return, ct_index
return, rgb_table ; pass through
The key is the use of
function, introduced in IDL 8.2.1. Use DETERMINE_COLORTABLE (I
couldn't think of a better name) to determine the color table
used in the graphic "g" above:
IDL> print, determine_colortable(g.rgb_table)
The idea for this program came from a discussion with Eddie
Haskell on the IDL Engineering team.
Tags: IDL 8