hyperion acheat atbdremote-sensing.nci.org.au/u39/public/html/hyperion/surface... · hyperion)atbd)...
TRANSCRIPT
Hyperion ATBD 1
Hyperion Processing
Introduction
Hyperion (http://eo1.usgs.gov/sensors/hyperion) (Pearlman et al, 2003) is a hyperspectral instrument on-‐board the Earth Observer one (EO-‐1) satellite (http://eo1.gsfc.nasa.gov/, http://eo1.usgs.gov/). NASA launched EO-‐1 on the 21st of November, 2000 as a one year investigation into advanced Earth observing techniques. The mission was extended to the present day under the control of the United States Geological Survey (USGS). The EO-‐1 mission included 2 other optical instruments, the Linear Etalon Imaging Spectral Array (LEISA) Atmospheric Corrector (LAC) and the Advanced Land Imager (ALI) (Ungar et al., 2003). Initially the ALI and Hyperion were going to be integrated to share the same fore-‐optics but time restraints meant that these were designed and built as separate instruments (Pearlman et al, 2003). Hyperion was designed, built, tested and delivered in less than 12 months to make the launch time so it is a remarkable achievement in such a short time. As the Hyperion mission was only designed as a technical demonstrator and had such a fast turn around time, the data produced require a number of processing steps if these are to be used for scientific investigation. Hyperion has 242 spectral bands ranging from 355.59 – 2577.08 nm. Due to poor signal to noise from some of these bands only 198 were actually processed (Pearlman et al, 2003). The sensor operates in ‘push-‐broom’ mode, which means that the sensor is not scanned across the surface like other sensor but only sees what’s in the instantaneous field of view. The instrument consists of two spectrometers, the Visible Near InfraRed (VNIR) and the Short Wave InfraRed (SWIR). The processed bands consist of 50 VNIR and 148 SWIR. The detector arrays for the spectrometers have 256 pixels in the across track direction and 128 and 256 in the spectral direction. Not all of the spectral pixels are used with 70 and 172 pixels used for each spectrometer respectively. The arrays are illuminated by a diffraction grating lined up in the across track direction. As light leaves the grating it illuminates pixels on the arrays based on the wavelength of the light. This gives a single across track line of 256 pixels with a spectral signature of 242 bands. As the satellite progresses along track more lines are built up generating what is known as a data cube.
Hyperion ATBD 2
Figure (i): Illustration of how the Hyperion data cube is built. The data cube is constructed as shown in figure (i) (CSIRO, 2011). The detector grid is illuminated with one dimension (across track) being the field of view of the sensor and the other dimension creating the spectral range. The image is built up over time as successive across track lines are samples. The Time axis in figure (i) is in the along track direction. The diffraction grating is aligned with the field of view axis. This push broom configuration can lead to problems in the data. A dead detector in the array will cause a line to appear in the along track direction in the across track position and band where the dead pixel is located.
Figure (ii): Band 11 (left) and band 96 (right) from the same Hyperion scene. Band 11 shows that the 1st and 6th across track detectors on the 11th spectral line are dead. This results in the lines in the image for band 11.
Band 96 is ok. The missing lines are repaired by interpolating values from pixels on either side of the line and replacing the missing value. This process is explained in more detail in the section on python modules. The other major problem associated with hyperspectral push broom sensors is spectral smile (Richter et al., 2011). This is caused by misalignment or aberration of the diffraction apparatus with the sensor grid along the field of view axis. The affect of this is shifting of the centre wavelengths of the light that lands on the
Hyperion ATBD 3
detector grid from one side of the field of view to the other. This is illustrated in figure (iii), which shows the wavelength in the Hyperion header file subtracted from the actual wavelengths for each position as reported in the Auxiliary file. The actual values were determined pre-‐launch and again post-‐launch by examining absorption features in the spectra. As most applications that allow viewing and processing of hyperspectral data are expecting a single range of wavelength for every pixel this affects any processing done with the data. The method employed here to remedy this problem is to interpolate each and every pixel spectra in the Hyperion files to a common wavelength range. Here we have chosen to use the wavelength range reported in each Hyperion header file. The algorithms to doe this are explained in the python modules section. Figure (iii) shows spectra from the VNIR spectrometer (bands1 and 18) and the SWIR spectrometer (bands 117 and 215). This shows that problem is only minor with the SWIR spectrometer. As described in the section on Python modules, each spectrometer is treated separately and the data recombined in the output product.
Figure (iii): Centre wavelength difference across the detector array for various bands
A number of other processing steps can be applied to the Hyperion data. Many of these steps are described in the paper by Datt et al, 2003. A Private communication with Dr. David Jupp, Principle Investigator for the Australian membership of the NASA EO-‐1 science validation team (retired), identified 11 processing steps that can be applied to Hyperion data. These steps are, 1. Fix bad pixels (low SNR bands and pixel dropouts) 2. Gain and Offset correction (to radiance) 3. Fix out-‐of-‐range values (artifact of process 2) 4. Interpolate wavelengths (corrects spectral ‘smile’) 5. De-‐spike (adjust extreme values based on image mean)
Hyperion ATBD 4
6. De-‐streak (accounts for differences in detector sensitivity: performed separately for each spectrometer)
7. Atmospheric correction 8. Sun angle correction 9. Cross track illumination correction 10. Minimum noise fraction (reduces uncorrelated spatial noise) 11. Empirical line correction to enable comparison between swaths Steps 2 and 3 relate to Hyperion Level 1B1 data where radiometric corrections have not been done. The AusCover data archive consists of Level 1R data, which has been radiometrically corrected already. Of the remaining 9 steps the 4 of most importance in descending order to achieve an adequate surface reflectance product are; 1.) Atmospheric correction, 2.) Fix bad bands and pixels, 3.) smile correction and 4.) de-‐streaking. The 4 steps post-‐atmospheric correction were not considered for inclusion in this work. De-‐streaking was considered and recommended by Dr. Jupp but it was decided to implement this module as time permitted, which it hasn’t. The atmospheric correction algorithm used for this work was developed using techniques in the literature and with the help of colleagues well versed in hyperspectral atmospheric correction. The algorithm and technical basis is described in some detail in the python modules section. As with all remote sensing products these data should be used with caution given the possible limitations of the data.
Python Modules
1.0) Introduction This document will describe the python modules used to process the archive of L1R files currently on the iVEC cortex system. 2.0) Pre-‐processing At the time of the preparation of this document there were only 2 pre-‐processing modules. These are designed to 1.) Replace missing or bad pixels in the data and ensure that bands that are known to be ‘dead’ are zeroed, and 2.) Correct for spectral smile. The following section will detail how the python modules address these issues within the data.
Module: fix_bad_bands_and_pixels.py Synopsis: This module emulated the behavior of the IDL Envi package “Workshop” function “Apply Bad Pixel List”. The Envi package and the underlying IDL code were provided by David Jupp, Retired fellow, Division of Marine and Atmospheric Science based in Canberra. Instructions on how to install and use this Envi package can be found in Datt and Jupp (2004). The function “Apply Bad Pixel List” is created in the Envi package by the IDL program “bad_pix_fix.pro". The python module “fix_bad_bands_and_pixels.py” is designed to exactly emulate the code segments
Hyperion ATBD 5
from “bad_pix_fix.pro" which work on the Hyperion data cube to fix bad pixels and write zeros over bad bands. Algorithm: The module reads in a list of bad bands and bad pixels. A list entry indicating a bad band results in all the pixel values in that band being set to zero. A bad pixel (element) in the detector array results in a column of bad pixels in a band. The detector array consists of 3 spectrometers each with a diffraction grating. The detector arrays consist of 256 across track and a number of pixels in the spectral dimension. As the satellite moves over the surface, lines are built up to form an image. Energy reaching the diffraction grating diffracts dependent on the wavelength so that pixels (detectors) in the spectral direction of the array are energized. If the across track line is the x direction and the along track is the y direction then the spectral direction is the z direction. The detector array produces x and z directions while the y direction is created by each successive activation of the sensing array. What this means is a bad detector (pixel) for a band at an across track position will appear as a line in the along track direction for a particular band. If a pixel in a particular band is shown as bad then the response of the algorithm depends on the across track position of the bad pixel. This can be expressed in pseudo-‐code (where x is along track, z is spectral band and y is across track) as: (Case 1) If bad pixel position at [x,z,0] then position [x,z,0] = position [x,z,1] (Case 2) If bad pixel position at [x,z,255] then position [x,z,255] = position [x,z,254] (Case 3) If bad pixel position at [x,z,1 -‐ 254] then position [x,z,1 -‐ 254] = (position [x,z,y-‐1] + position [x,z,y+1])/2 where y is a number from 1 to 254. The python code segment which executes this algorithm is: if sort_pixels[indx] == 0: (If band is bad, set all in_cube[:,z,:] = 0 values to zero) elif sort_pixels[indx] == 1: (Case 1 from above) in_cube[:,z,0] = in_cube[:,z,1] elif sort_pixels[indx] == 256: (Case 2 from above) in_cube[:,z,255] = in_cube[:,z,254] elif (sort_pixels[indx] > 1) and (sort_pixels[indx] < 256): (Case 3 from above) for x in range(0,colm_size-‐1):
Hyperion ATBD 6
in_cube[x,z,sort_pixels[indx]-‐1] = int(round((in_cube[x,z,sort_pixels[indx]-‐2] + in_cube[x,z,sort_pixels[indx]])/2)) Module execution: The module is designed to be executed from the command line and requires 2 inputs. These are the Hyperion L1R file to be processed and the list with bad bands and pixels. These inputs are entered on the command line using switch options so the order is not essential. The command line execution is: python fix_bad_bands_and_pixels.py –i {Hyperion L1R path and filename} –l {bad band and pixel list path and filename}
When this module is run on another system the call to python can be removed as long as the python path is included in the python script. Calling the script with the switch –h will display the script usage.
The module has 4 distinct parts. The first part reads in the file that contains the bad band and pixel locations. It then sorts the list by band number. The band numbers and pixel positions are stored to separate arrays, which are passed to the code segment, which performs the fixes (see above)
The second part reads in the Hyperion L1R hdf file. This uses Pyhdf to read in the data cube as in_cube, file attributes as file_attributes and data attributes as data_attributes.
The third part performs the corrections to the data cube as shown in the code segment above.
The forth part writes out a new L1R file which is designated with “_BP_FIX” at the end of the filename just before the file suffix “.L1R”. This also uses Pyhdf functionality. The repaired data cube is written into the new file along with the data attributes and file attributes from the original file as nothing has really changed. The only addition to the file attributes is the line “Post processing: Bad bands and pixels fixed, processed by Curtin RSSRG on {system date and time inserted here}” Result: This module results in a new file being produced where, hopefully, all of the bad bands and pixels errors in the data cube have been addressed. As this is only a temporary file, a header file has not been produced. To view this file in something like Envi, copy the header file from the original file and change the name to correspond to the new file name. When this module is integrated into a processing system, the “_BP_FIX” file will be deleted as soon as it has undergone further processing. Module: fix_spectral_smile.py Synopsis: This module emulated the behavior of the IDL Envi package “Workshop” function “Desmile”. The function “Desmile” is created in the Envi package by the IDL program “Desmile.pro". This module reduces the affect of band centre shifting across the spatial direction of the data cube which results in spectral frown or smile depending on which way you look at it. While there are other methods to reduce spectral smile, interpolation to a common set of band centres (Jupp et al., 2003) produces the best results without completely contaminating the spectra.
Hyperion ATBD 7
Algorithm: The Hyperion instrument has 2 spectrometers that measure from around 400 – 1000 nm and 900 – 2500 nm respectively. This means that there are overlapping bands. Bands at either end of both spectrometers are set to zero due mainly to low signal levels. This gives spectra as shown in figure 1.
Figure 1.) Hyperion spectra with the VNIR spectrometer output shown as blue, the SWIR shown as red and the wavelength in nm displayed on the x-‐
axis Given the overlap it was decided to perform 2 spectral interpolations, one for each spectra. This is sensible anyway as the smile affect is more prevalent in the VNIR spectrometer. The other issue is that bands on either end of the spectral regions are set to zero. If an interpolation is performed on this data as is then there is significant “ringing” caused by rapid changes in values. This is evident in figure 2.
Hyperion ATBD 8
Figure 2.) The original Hyperion spectra in blue and the interpolated spectra (dashed green line). The red circles indicate the areas where ringing can occur due
to rapid changes in value. To combat this the zero values at either end of the spectra are set to the first non-‐zero proceeding or preceding value depending on which end of the spectrum they occur at. One this is done then the spectra is interpolated. The Python module Scipy has a few inbuilt interpolation functions. Here the function interp1d is used. For further explanation of the function and the source code refer to http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html. This function has a few different interpolation methods. Tests were performed for both linear interpolation and using a cubic spline interpolation. The results of this are shown in figure 3.
Hyperion ATBD 9
(a)
(b) Figure 3.) Linear interpolation (a) and cubic spline interpolation (b) are compared
with the original spectra.
Hyperion ATBD 10
From inspection neither method appears to be vastly superior to the other. The linear interpolation does seem to produce less ringing around rapid changes of value. The actual band centres for each Hyperion scene are located in the auxiliary file. This gives the band centre locations for each position in the across track pixels of the scene. Each pixel spectra is then interpolated to the band centres values from the image header file, as these do not change from file to file. This way all scenes will be interpolated to the same centres and can be compared directly.
Module execution: The module is designed to be executed from the command line and requires 3 inputs. These are the Hyperion L1R file or preferably the L1R file that has had bad lines and pixels fixed, the auxiliary file and the header file. These inputs are entered on the command line using switch options so the order is not essential. The command line execution is: python fix_bad_bands_and_pixels.py –i {Hyperion L1R path and filename} –a {Hyperion auxiliary path and filename} –e {Hyperion header path and filename} This module has three part, the first of which reads in the three input files, parses out the required information and loads this into arrays. The second part does the actual processing and the final part writes out a new file. The interpolation is done for every pixel in the scene. This means that a 256 pixel wide by 5000 pixel long scene will require 1.28 million interpolations. After some tweaking of the code this process takes less than 5 minutes on a 6500 line file when run on a dual-‐core iMAC and is about 20% quicker when run on the iVEC system. 3.0) Atmospheric Correction
The atmospheric correction of the Hyperion data involves a number of steps that are divided over a number of python modules. Due to a total lack of imagination, most of these modules explain their function in the file name.
The process can be broadly divided into a few basic steps; 1.) Extract information from the Hyperion files to set up radiative transfer (RT) runs and execute the RT program, 2.) use these files to produce a water vapour (WV) product from the Hyperion file, 3.) create lookup files from the RT files, 4.) using the lookup files and the WV product, perform atmospheric correction (AC) on the file.
This section will detail the operation of the python modules that perform the functions described in the previous paragraph. These modules are designed to be run stand-‐alone but may require previous modules to be run to produce the appropriate input files. Module: CIBR_calculate_ratios.py Synopsis: This module takes a Hyperion L1R scene and calculates a flat file (ENVI dat file with associated header) of Continuum Interpolated Band Ratios (CIBR) using the equations from Schlapfer et al., 1998. The CIBR ratio values are
Hyperion ATBD 11
determined from the L1R data using a water vapour absorption feature. The ratio is determined using a band centred on the absorption feature and 1 band either side that do not respond to the level of water vapour in the atmosphere. The deepening of the feature indicates a higher level of atmospheric water vapour and thus can be exploited to estimate this level. Algorithm: The algorithm is an implementation of the equations for the CIBR method shown on page 354 of the paper by Schlapfer et al., 1998. This is,
!!"#$ =!!
!!!×!!!!!!!×!!!
where;
!!! =!!! − !!!!! − !!!
!!! =!! − !!!!!! − !!!
*
Figure 4: This shows band averaged radiance values for Hyperion bands around the 1132 nm water vapour feature. The radiance values were
produced by the MODTRAN5 RT model.
* The actual equation in Schlapfer et al., 1998 has the terms in the numerator reversed and is incorrect.
(1)
Hyperion ATBD 12
Figure 4 shows where the bands are situated in regards to the absorption feature. This data is modeled and shows how the ratio determined from the Hyperion data should behave for different levels of atmospheric water vapour. This modeling will be discussed more thoroughly in later sections. Figure 1 shows the sharp absorption feature in actual Hyperion data. This is seen in the red trace that shows radiance data (as counts) for the second radiometer. Each pixel in the scene is processed which results in a single band data file with a ratio value for each along track by cross track pixel position. The output file is written out as an ENVI format .dat file with associated header. Module execution: This module requires three input files. These are a Hyperion files containing radiance values, the associated header file and a template file for the .dat file associated header. This module should work with either the original L1R file, the output of the band pixel fix process, the output of the smile correction process or any Hyperion file where the format of the file and header remain unchanged. The template file contains the following information; ENVI description = { Continuum Interpolated Band Ratio} samples = 256 lines = 3400 bands = 1 header offset = 0 file type = ENVI Standard data type = 5 interleave = bsq sensor type = Unknown byte order = 0 wavelength units = Unknown band names = { CIBR ratios} The only change made for each Hyperion file is to the output name and the number of lines and pixels. The CIBR data is written out as a flat binary file. This file can be read into ENVI but can also be read by Spectral python. The module can be run on the command line or in a script like; python CIBR_calculate_ratios.py -‐i (hyperion_radiance_file} -‐e (hyperion_hdr_file} -‐t (output_template_file) The module will output a .dat file and a .hdr file with the naming convention (file_base_name)_CIBR_ratios.hdr and (file_base_name)_CIBR_ratios.dat, i.e. EO1H0890832006187110K1_CIBR_ratios.dat. Module: Create_tape5_files.py
Hyperion ATBD 13
Synopsis: Downstream processes such as water vapour retrieval and atmospheric correction require radiative transfer model output based on the conditions of viewing from Hyperion. This module gather information from metadata files associated with the Hyperion radiance file and uses this to create a set of tape5 files based on the viewing conditions of the overpass. The tape5 files are used by MODTRAN5 to execute radiative transfer modeling based on the viewing conditions. Algorithm: There is no algorithm as such so a brief description of the module operation will be given. This module requires a template tape5 file as it only changes a few key parameters and does not write the tape5 file from scratch. The form of the file is extremely important. The module is not at all clever as it removes and replaces text based on line and position so changing the template file will in all likelihood cause the entire processing chain to fail. The module also requires a .MET file for each Hyperion scene. The .MET file contains information on the geographic position of swath, day and time of sampling (although the day can be derived from the file name). Using the USGS data explorer tool (http://earthexplorer.usgs.gov/) it’s possible to place a bounding box around the area of interest and generate a .csv file that contains information about Hyperion overpasses within the bounding box for the archive of Hyperion files. This contains a field for look angle. The Hyperion imager can look up to approximately 20 degrees from nadir at the equator. This look angle is extracted from the .csv file to be used in the creation of the tape5 file. There are situations where an overpass in the AusCover archive is not included in the .csv file. If this is the case then nadir viewing is assumed and the look angle is 0 degrees. The 4 parameters that are changed based on metadata are the look angle, day of year, swath centre latitude, swath centre longitude. These are derived from the .MET file and the .csv file. Attempts have been made to account for variations in the .MET file (missing lines and values) but a few Hyperion files have required that the .MET files be manually edited. The other parameters that are changed are the surface reflectance and the column water vapour (CWV) amount. Two surface reflectance figures are used (0.5 and 1.0) and 34 CWV amounts are used ranging from 0.05 to 5.0 g.cm2. The CWV amounts are chosen to give a reasonably smooth progression on the curve that is produced when the CWV amount is plotted against the CIBR ratio that results from the MODTRAN modeling. Interpolated plots are shown for various surface reflectance values in figure 5.
Hyperion ATBD 14
Figure 5: Interpolated CIBR vs CWV for various surface reflectance values In all 68 tape5 files are created. This module does 2 other important tasks. The first of these is to create a mod5root.in file. This file lists all of the tape5 files that need to be processed. When MODTRAN5 is run from a directory that does not contain the executable, it searches that directory for a mod5root.in file. If it doesn’t find it, it will search in the directory that contains the executable. The other important task when executing in a remote directory is to create a symbolic link to the MODTRAN DATA directory. I think you can implicitly write the path to the required data files in the tape5 file but I have never been able to get it to work. Creating the symbolic link means that MODTRAN will sort all of this out for you. MODTRAN is executed from the command line (which could be done from this module) but at the time I decided to do this from within the perl module that links the python modules but more on this later. Module execution: This module can be run independently like all of the other modules. It is run like: python Create_tape5_files.py -‐i (tape5 template file) -‐m (.MET file) -‐e (Hyperion overpass .csv file) -‐t (directory containing the tape5 files) -‐d (path to the MODTRAN DATA directory) -‐l (name of the processing log file name) Module: Make_final_lookups.py Synopsis: Continuing on with the lack of imagination naming convention, this module, as the name suggests makes a final set of lookup files. Each lookup file is produced from 2 output files from MODTRAN with the same input values apart from surface reflectance. Each lookup file is for a different water vapour value
Hyperion ATBD 15
and is matched for the observational geometry for each overpass. For each scene then 34 lookup files are produced. Algorithm: The production of the lookup files is based on the work of Guanter et al, (2009), Rodger, (2008) and Rodger, (2011). The aim of the Guanter et al. approach is to decouple the surface radiative effects from those of the atmosphere. The surface reflectance can then be estimated by providing the at-‐sensor radiance as the atmospheric radiative effects are estimated by the MODTRAN outputs. Equation 2 and 3 (Guanter et al, 2009) show the at-‐sensor atmospheric path radiance !! ! and the total at-‐sensor radiance !!"# ! respectively.
!! ! = !! 0 +!!"#↑ !!↓ ! !
!
!!"# ! = !! ! +!!"#↑ !!↓ ! !
!
Here ! is the surface reflectance, !!"#↑ and !!"#↑ are the spectral transmittance for diffuse and direct radiation respectively. The term !!↓ ! represents the total downwelling flux at the surface and can be expressed as,
!!↓ ! = !!"#↓ !! + !!"#↓ ! where !!"#↓ and !!"#↓ represent the direct and diffuse downwelling flux at the surface and !! is the cosine of the solar zenith angle. !!"#↓ has a component that represents the multiple scattering events that occur between the surface and the atmosphere and is still coupled to the surface. Combining equations 2 and 3 and re-‐writing allows the downwelling flux to be expressed without multiple scattering (!!↓ 0 ) (essentially de-‐coupling this from the surface reflectance) where this effect is expressed in a term for the spherical albedo (S) of the atmosphere as,
!!"# ! = !! 0 + !↑!!↓ ! !! !!!"
where !↑ = !!"#↑ + !!"#↑ . Now that the surface reflectance has been decoupled from all of the other radiative components, equation 5 can be re-‐written to express ! as (Rodger, 2008),
! =!!!"#!!! !
!!↓ ! !↑
!!!!!"#!!! !
!!↓ ! !↑!
If A is defined as,
(2)
(3)
(4)
(5)
(6)
Hyperion ATBD 16
! = ! !!"#!!! !!!↓ ! !↑
Then the equation to determine the surface reflectance can be written as,
! = !!!!"
Using equations 7 and 8 we now have a method to estimate surface reflectance from the at-‐sensor radiance (!!"#) if we can determine !! 0 , !!↓ 0 , !↑ and !. Using the output tape7 or tape7sc files from MODTRAN5, these parameters can be calculated from 2 runs with different reflectances. Here the tape7sc file has been used, as it outputs data at wavelength selectable intervals (Berk et al, 2011). An example of the output from this type of file is shown in figure 6. The columns, explanations and how these parameters were calculated is shown if figure 7. To calculate the required parameters from the 2 run method the following equations are used,
!! 0 = !!!!↓ !! !!! !! !!!!!↓ !! !!! !!!!!!↓ !! !!!!!↓ !!
!!↓ 0 = ! !!" !! !!! ! !!!!!!!!↑
! = !!↓ !! !!!↓ !!!!!!↓ !! !!!!!↓ !!
!!"#↑ =! !!! !! − !! 0
!!!!↓ !!
As !!"#↑ can be directly read from the tape7 files from the TRAN column we can calculate !↑ = !!"#↑ + !!"!↑ . To calculate equation 9, data is required from the SOL SCAT column for both runs. Equation 10 requires data from the TOTAL RAD column and equation 12 requires data from the SOL SCAT column. Equations 10 and 11 can be evaluated with data from either MODTRAN run as long as the retrieved data is matched to the radiative components for that run. To evaluate equation 11 we need to calculate both !!↓ !! and !!↓ !! using,
!!↓ ! = !!!" !!!"#↑ !
(7)
(8)
(9)
(10)
(11)
(12)
(13)
Hyperion ATBD 17
where !!! is retrieved from the GRND RFLT column for both MODTRAN runs. Each of the 34 lookup files will contain values for !! 0 , !!↓ 0 , !↑ and ! at each of the wavelength values within the tape7sc file. This gives 2200 values at 1nm resolution over the range of wavelengths where Hyperion retrieves data. This module is written is such a way that it will accept any number of input files as long as the files naming convention remains the same. This means that either more runs with a greater range of CWV can be run or if a more complicated type of lookup file system was envisaged with other variable atmospheric parameters (such as aerosol optical depth), then this module will adapt. As long as each pair of input tape7sc file ends with _0.50.7sc and _1.00.7sc. Module execution syntax: This module is capable of being run independently as are the other modules. It can be executed from the command line using, python Make_final_lookups.py –i (working directory). The working directory will be the directory that contains the tape7sc files produced from the multiple MODTRAN runs. The script will search and list all files ending with _0.50.7sc and _1.00.7sc. A loop is executed for each set of files with the values from each column of the tape7sc files (see figure 6) read into multi-‐dimensional arrays, 1 array for each file. The appropriate column values are used to calculate parameters as described above. For each set of files a lookup file is written which contains columns for 4 required values. A separate file is produced which contains the wavelength values. Subsequent modules use both of these files.
Hyperion ATBD 18
MMF 1 2 2 -‐1 1 1 1 1 1 1 1 0 0 300.000 0.50 1 1 1 3 0 0 50.00000 0.00000 0.00000 0.00000 0.30000 -‐99.000 -‐99.000 -‐99.000 -‐99.00000 -‐99.00000 -‐99.00000 0.050000 0.000592 ! H2O & O3 COLUMNS [GM/CM2] 36TROPICAL MODEL 100.00000 0.30000 169.46964 101.43521 0.16651 0.00000 0 0.00000 0 2 187 0 -‐32.24763 208.65001 22.73250 171.41467 23.50100 0.00000 0.00000 0.00000 3905.0 29415.0 1.0 1.0RN NGAA 0 0 0.000 0 0.000 0 1.000 WAVLEN(NM) TRAN PTH_THRML THRML_SCT SURF_EMIS SOL_SCAT SING_SCAT GRND_RFLT DRCT_RFLT TOTAL_RAD REF_SOL SOL@OBS DEPTH DIR_EM TOA_SUN BBODY_T[K] 350.000 0.4182395 0.0000E+00 0.0000E+00 0.0000E+00 5.7267E+00 1.7976E+00 2.0193E+00 4.0986E-‐01 7.7460E+00 6.17E+00 1.14E+02 0.872 0.5000 1.1364E+02 2108.620 351.000 0.4215315 0.0000E+00 0.0000E+00 0.0000E+00 5.8589E+00 1.8438E+00 2.1001E+00 4.3255E-‐01 7.9590E+00 6.51E+00 1.17E+02 0.864 0.5000 1.1703E+02 2107.085 352.000 0.4248399 0.0000E+00 0.0000E+00 0.0000E+00 5.5999E+00 1.7670E+00 2.0423E+00 4.2717E-‐01 7.6422E+00 6.43E+00 1.13E+02 0.856 0.5000 1.1262E+02 2098.253 353.000 0.4283030 0.0000E+00 0.0000E+00 0.0000E+00 5.6811E+00 1.7977E+00 2.1108E+00 4.4878E-‐01 7.7919E+00 6.75E+00 1.15E+02 0.848 0.5000 1.1492E+02 2095.923 ~ 1847.000 0.2381447 5.2464E-‐07 1.3824E-‐08 3.4637E-‐07 2.7209E-‐03 1.8792E-‐03 6.6952E-‐02 6.4898E-‐02 6.9674E-‐02 9.77E-‐01 1.45E+01 2.805 0.5000 1.4504E+01 490.268 1848.000 0.1661969 5.4503E-‐07 1.2811E-‐08 2.4670E-‐07 1.9604E-‐03 1.6168E-‐03 2.7353E-‐02 2.6573E-‐02 2.9314E-‐02 4.00E-‐01 1.46E+01 2.999 0.5000 1.4567E+01 464.758 1849.000 0.2973246 5.4172E-‐07 1.8017E-‐08 4.4746E-‐07 3.0324E-‐03 2.0842E-‐03 8.0784E-‐02 7.8468E-‐02 8.3817E-‐02 1.18E+00 1.48E+01 1.896 0.5000 1.4833E+01 495.672 1850.000 0.4262851 5.2997E-‐07 2.1766E-‐08 6.4671E-‐07 4.1936E-‐03 2.5397E-‐03 1.4330E-‐01 1.3921E-‐01 1.4749E-‐01 2.10E+00 1.49E+01 1.066 0.5000 1.4946E+01 513.996 1851.000 0.5159544 4.8220E-‐07 2.2684E-‐08 7.9184E-‐07 5.5922E-‐03 2.8628E-‐03 2.1949E-‐01 2.1274E-‐01 2.2508E-‐01 3.20E+00 1.49E+01 0.785 0.5000 1.4936E+01 528.578 ~ 2546.000 0.3044265 1.9863E-‐04 2.7837E-‐06 1.1183E-‐04 3.7034E-‐04 2.6503E-‐04 1.7267E-‐02 1.6912E-‐02 1.7948E-‐02 2.55E-‐01 4.62E+00 1.448 0.5000 4.6189E+00 361.315 2547.000 0.2616541 1.9062E-‐04 2.4399E-‐06 9.6345E-‐05 3.3779E-‐04 2.4260E-‐04 1.5285E-‐02 1.4968E-‐02 1.5910E-‐02 2.25E-‐01 4.59E+00 2.118 0.5000 4.5881E+00 358.456 2548.000 0.1446764 1.8110E-‐04 1.8624E-‐06 5.3624E-‐05 2.2524E-‐04 1.8483E-‐04 6.7648E-‐03 6.6229E-‐03 7.2248E-‐03 9.97E-‐02 4.60E+00 3.151 0.5000 4.5982E+00 341.263 2549.000 0.2101394 1.9165E-‐04 2.2853E-‐06 7.8573E-‐05 2.7501E-‐04 2.1692E-‐04 9.7362E-‐03 9.5220E-‐03 1.0281E-‐02 1.43E-‐01 4.61E+00 2.473 0.5000 4.6129E+00 348.604 2550.000 0.2665780 2.0561E-‐04 2.5799E-‐06 9.9933E-‐05 3.1993E-‐04 2.4588E-‐04 1.2347E-‐02 1.2073E-‐02 1.2973E-‐02 1.82E-‐01 4.61E+00 1.919 0.5000 4.6060E+00 353.588 -‐9999.
Figure 6: Example of an excerpt MODTRAN5 tape7sc file.
Hyperion ATBD 19
Figure 7: Copy of table 1 from Rodger, 2009 (with permission)
Hyperion ATBD 20
Module: Calculate_wv_V2.py Synopsis: This module produces a water vapour field for the Hyperion scene. It does this by comparing the CIBR file produced from the Hyperion data to CIBR data generated from modeled MODTRAN data. It interpolates the modeled CIBR vs CWV values to match the actual CIBR values from the Hyperion data. Algorithm: This module has 3 basic steps. The first step is to calculate CIBR ratios from the tape7sc files. These files are described in figures 6 and 7. Calculation of the CIBR is exactly as expressed by equation 1. Figure 4 shows graphical output of the water vapour feature used for this determination. This figure shows data from MODTRAN where, for a set of geometric parameters (sun/satellite orientation, surface target location), a number of different CWV values are used. Each CWV value has an associated CIBR calculated. The data here are total radiance values taken from the TOTAL RAD column of the tape7sc file. These data are then band averaged to the spectral resolution of Hyperion. Each of the Hyperion input files has been corrected for spectral smile, which means that they all have the same set of band centres. The spectral response of the Hyperion spectrometers is reported as being a Gaussian around the band centres with each band having a specified FWHM. These values are contained in the L1R header file. A normalized Gaussian envelope is produced around the wavelength that is closest to the band centre so that a scaling factor is produced for each wavelength of the TOTAL RAD. This is shown graphically in figure 8.
Figure 8: Normalised band response function overlaid with the Total Radiance
Hyperion ATBD 21
Each of the points shown in the graph are multiplied together and the resultant is averaged to produce a band equivalent value. As the Gaussian function is continuous this would result in every TOTAL RAD value being included in the average. The actual range of the radiometer band will be finite (but I don’t know what that is) so a cut off is employed here to ignore all values where the Gaussian function in below or equal to 0.001. This approach is employed for the three bands required to produce the CIBR so that we get CIBR results that are equivalent to the Hyperion bands. This gives a set of 36 CIBR values for the range of CWV that were used to produce the tape7sc files and the lookup files. The second step of the water vapour retrieval process is to interpolate this set from 36 to 200 values using a cublic spline interpolation function within python. The results of the interpolation are shown in figure 5. All of the CWV retrievals done with this module use the curve associated with a 0.5 surface reflectance. Figure 5 shows that there is a difference in the CIBR vs CWV relationship for different values of surface reflectance.
Figure 9: CIBR vs Water vapour uncertainty for various surface reflectance values
Figure 9 shows differences in CWV values at a selection of CIBR values for various surface reflectance values. Here all the CWV values have had the CWV from the 1.0 surface reflectance value subtracted. This gives an indication of the error in retrieved CWV value for a CIBR value if the surface reflectance is not 0.5 (which it is not likely to be for the three bands that are used to calculate the CIBR). It is expected that surface reflectance would be region of 0.10 to 0.50 and the majority of the CIBR values to be around 0.2 to 0.6. This would give a maximum error of around 0.5 for the water vapour retrieval (assuming the
Hyperion ATBD 22
Hyperion CIBR retrieval was without error, which it is not). This is considered to be acceptable. If a more accurate CWV retrieval were required then a more sophisticated method would need to be used. The final step in the process is to actually retrieve the CWV data. This is done using the CIBR field generated for the Hyperion scene from the CIBR_calculate_ratios.py module. Each pixel CIBR value is compared to the curve generated from the MODTRAN data. The two nearest values are chosen from this and a linear interpolation between the points is done. The module will also try to compensate for pixels where the retrieval fails. This can result in NaN and infinite values as well as values outside the range of modeled CWV’s. These failed values are replaced with the mean CWV from the scene where the retrieval hasn’t failed. The CWV field is saved as an ENVI .dat file complete with header file so it is able to be opened either in ENVI of with spectral python. This module (and a few others) also write data into a log file. This particular module reports the name of the water vapour file, mean, median and standard deviation as well as the water vapour feature centre wavelength. Module execution: This module is executed from the command line using, python –i {CIBR_file_header} –e {Hyperion_file_header} –d {tape5_directory} –l {log_file_name}. The CIBR_file_header is generated by the CIBR_calculate_ratios.py module. The header file for the CIBR data file already contains the appropriate line, pixel, data type, endian etc so this is renamed to match the WV file name and the field decription in the file is changed to Water vapour g.cm^2. It also is used to open the CIBR file for generation of CWV values. The Hyperion header file is the original L1R header file that contains the band centres and FWHMs. The tape5 directory is essentially the working directory. This is here so that the module can be run independently by specifying where the tape7sc files are located, if this data has been generated previously. The log file is generated by the perl script which links all of the processing modules together. In order for this module to be run independently the few lines that add data to the log file would need to be removed, or a further run time option added to turn this on or off. Module: Atmospheric_correction_V3.py Synopsis: This module as the name suggests performs atmospheric correction or compensation as some refer to it. Compensation is a more concise description of this process, as the radiative transfer effects through the atmosphere are not completely corrected, only compensated for. This module takes the lookup files, CWV data and uses these to calculate an estimate of the surface reflectance. Algorithm: This module first of all opens all of the data required to calculate a surface reflectance product. This includes the water vapour file, the lookup files and the Hyperion L1R data. This will work with an L1R file that has been corrected for bad lines and spectral smile or a virgin file, as long as the header file and file formats are the same.
Hyperion ATBD 23
The second function of the module is creating 2 masks based on the CWV field for the scene. For each pixel a number between 1 and 36 is placed in the masks, one mask indicates the lower value of CWV from the lookup files and the other mask the upper value from the lookup files for which the retrieved pixel value of CWV falls between. These mask values for each pixel are then used later to determine which set of lookup values will be interpolated between to get the final set of values that will be used to determine the surface reflectance. The third step is to take the lookup table values and convert these into band equivalent values. This is done in the same manner as the band equivalent calculations performed by the Calculate_wv_V2.py module. Here however values are calculated for every band of Hyperion. This results in four arrays of 242 x 36 values for !! 0 , !!↓ 0 , !↑ and !. As these arrays are indexed by the CWV amount and we have previously constructed two masks with the positions of the upper and lower CWV for each pixel, we can now select the values of the 4 components from the !! 0 , !!↓ 0 , !↑ and ! arrays that will be interpolated and used in the final surface reflectance calculation. The surface reflectance is now calculated for each pixel ( !, ! ) using equations 7 and 8 so that
! !, ! = !!!"# !,! !!! ! !,!
!!↓ ! !,! !↑ !,!
! !, ! = ! !,!!!! !,! ! !,!
where !! 0 !, ! , !!↓ 0 !, ! , !↑ !, ! and ! !, ! have all been band averaged from MODTRAN data and interpolated based on the retrieved CWV value. The !!"# !, ! data is read from the corrected L1R data and is converted to the same radiance units as the MODTRAN values. This involves dividing the Hyperion data for the VIS/NIR spectrometer by 400.0 and the NIR spectrometer by 800.0. This will convert the integer values within the L1R file to float values for the reflectance calculations. The last data processing step is to convert all of the calculated reflectance values to unsigned integer values. All reflectance values are first of all multiplied by 10000.0 and then rounded to the nearest whole number. This gives a data cube with values ranging from 0 to 10000 representing reflectance values of 0.0000 – 1.0000. Converting the float reflectance values to unsigned integer values saves a significant amount of space. Finally the data are output as both hdf and ENVI bil formatted data. Module execution: This module can be executed from the command line as python Atmospheric_correction_V3.py -‐i {input L1R file} -‐e {input L1R file hdr} -‐q {band wavelengths file} -‐l {working directory – where the lookup files are}/ -‐x {water vapor file hdr} -‐f {envi hdr template} As stated above, this module will work on the original L1R file, one that has been corrected for bad pixels, one that has been smile corrected or one that has had
(14)
(15)
Hyperion ATBD 24
both steps done. If further modules are added to perform other corrections then it will work on these as well as long as the format of the file and the header file do not change. Module: produce_wv_quality_mask_V2.py Synopsis: This module is not in any way essential and could be removed if desired. All it does is give an indication where the wrong CWV amount was retrieved per pixel. It does this by examining features in the spectra that are introduced when the CWV amount used in the calculation of reflectance is wrong. It creates a mask of the good and bad pixels (good =1, bad = 0). Multiplying the data by the mask sets all bad pixels to zero. This mask is not saved but the values are used to give a percentage of pixels per scene which failed the quality test. Algorithm: This quality mask is provided as an indication of the success of the water vapour retrieval module. There is no startling scientific basis for the tests involved as they were created from visual inspection of the spectra. From inspection the behavior of the bands centred on 1104.19 nm, 1124.28 nm and 1134.38 nm (Hyperion bands 96, 98 and 99) are reasonably distinct if the CWV amount used for the reflectance calculation is incorrect.
Figure 10: Three spectra showing where CWV used for reflectance calculations were too high, too low and in the vicinity
Hyperion ATBD 25
Figure 11: Three spectra where the CWV used for reflectance calculations were too high, too low and in the vicinity. The About right spectra has been offset to sit with
the other spectra
Figures 10 and 11 show three spectra where the CWV retrieved is too high, too low and about right. What this means when the surface reflectance is calculated, the atmospheric transmittance is overestimated (too low condition), underestimated (too high condition) or are about right. This produces an underestimation of the surface reflectance (too low condition), overestimation of surface reflectance (too high condition) or no affect. As the atmospheric transmission of some bands is not affected by CWV this gives a way to compare the success of the CWV retrieval. With the very simple method used here, bands 98 and 99 are subtracted from band 96. These bands are shown as the magenta dots, yellow dots and grey dots respectively in figure 11. If the resultant is less than or equal to -‐1000 (reflectance of -‐0.1) then the CWV amount is deemed too high, if the resultant is greater than or equal to 1000 then the CWV amount is deemed too low.
!ℎ!"! !!" − !!! ≤ −1000 !ℎ!" !"# = !"" ℎ!"ℎ
!ℎ!"! !!" − !!" ≥ 1000 !ℎ!" !"# = !"" !"# The threshold value of 1000 (difference from band 96) was chosen to be conservative and hopefully outside of any natural variation due to surface type. This could be tested using MODTRAN with a number of different surface types, CWV values and whatever other variables one wishes to employ but the tests performed here are not based on this type of investigation and should be used cautiously.
(16)
Hyperion ATBD 26
Two masks (one for too high, one for too low) are constructed by performing the subtractions from equation 16 and then setting values outside the threshold to 0. The masks are then multiplied together which will set all values outside of either threshold to zero. The values in the resultant mask that are not zero are now set to 1. If required each band of the data could be multiplied by the final mask. Any mask value which is zero would zero out the data for a bad pixel and the good pixel values would remain unchanged. The percentage of bad pixels is calculated and a failure rate is reported within the processing log file. From observation a high failure rate percentage indicates that the bands used to retrieve the CWV are likely to be very noisy and streaky. Module execution: The module is run with the following usage. python produce_wv_quality_mask_V2.py -‐i {Reflectance_file_(hdf format)} -‐e {hyperion_file_hdr} -‐t {cibr_template_hdr} -‐l {log_file}. Module: image_swath.py Synopsis: This module makes an RGB image of the Hyperion swath. It uses a package called pyhdf to open the HDF reflectance file created previously. It selects bands closest to process red, green and blue and saves greyscale images of these bands as .png files. The calling perl script (discussed later) executes bash commands to run ImageMagick, which combines the three images into the RGB image. Algorithm: The data cube is loaded into a 3 dimensional array in the BIL format. Three slices are extracted from the cube, 1 each for bands 29, 20 and 12 (640.5 nm, 548.92 nm, 467.52 nm). For reasons I am unable to explain, these slices result in a 3 dimensional array where the third dimension contains a single element. This is the same as a 2d array but causes trouble when trying to same these as images. A numpy function called squeeze is used which converts the data cube slices to 2d arrays. The three images are then saved as .png images. The perl script calls the ImageMagick functions convert and composite. The first three calls to convert perform a linear linear stretch on the three .png files created previously. This ‘brightens’ the images which tend to be quite dark. If the image has cloud in it these tend to saturate. Composite is called to create the RGB by compositing the three images together. Finally convert is called once again to sharpen the final RGB image. This does not always create the best image possible but in general is does give a good visual indication of the surface being imaged by Hyperion. Module execution: This module is run from the command line as python image_swath.py -‐i {reflectance file in hdf format}
Hyperion ATBD 27
Module: make_quicklook.py Synopsis: This module uses basemap to plot the Hyperion swath location on an Australian map. It embeds the Hyperion RGB image on the map. Algorithm: This module makes extensive use of basemap, which is a toolkit for matplotlib. This allows data to be transformed spatially so that it can be plotted on various map projections. It will also read shape files and allow these to be plotted as well. The module sets up a basemap. This defines a set of extents for the map. These are currently hardcoded to latitude 6S – 45S, 108E – 156E. The module draws a landmask and colours this so it is distinctive from the ocean. There are lines commented out in the file that replace the landmask with a blue marble image. These had to be removed as for some reason they ceased to function properly on the iVEC system. This functionality can be added in if the software is installed on another system. A shape file that contains a high-‐resolution coastline and Australian state boundaries is opened and added to the map. Each .MET file has the corner coordinates for the extent of the Hyperion swath it is associated with. This module opens the .MET file and extracts these corner coordinates. A polygon is drawn on the base map using the corner extents derived from the .MET file. The .MET file also contains the site centre location. This is read from the file and is written into a label on the map next to the polygon that has been drawn on the map. The module also draws grid lines on the map. The swath image created earlier is imbedded in the map on the left hand side. Each map has a title added that specifies the date of capture of the image. Module execution: Command line execution usage is python make_quicklook.py -‐q {name of the swath image} -‐m {hyperion .MET file} -‐i {hyperion header file} -‐o {overpass csv file} -‐s {shape file name}
Perl Script -‐ Execute_Atmospheric_Correction.pl
This script is used to link all of the python modules and associated processes together. It execute bash commands as required, ImageMagick commands as required, moves files around and cleans up working directories. There are many paths and file locations hard coded into this script. If this was to be run on another system then this is the place to change these locations as required. All of the hard coded file locations and paths are passed through to the python modules so adapting to another system should only require rewriting this script and not a bunch of python modules. This script is designed to be executed in a directory that contains the extracted data from an L1R .tgz file. This includes the L1R file in hdf format, the associated header file, the .MET file and the .AUX file.
Hyperion ATBD 28
Figure 12: Module execution order. The red boxes indicate commands/functions
executed in bash and the black boxes represent the python modules.
Find *.L1R file
Execute fix_bad_bands_and_pixels.py
Find *_BP_FIX.L1R file, Find *.AUX file
Execute fix_spectral_smile.py
Find *_BP_FIX_SMILE_FIX.L1R file, Find *.MET
Execute CIBR_calculate_ratios.py
Execute Create_tape5_files.py
Launch Mod90_5.2.1.exe
Execute Make_final_lookups.py
Execute Calculate_wv_V2.py
Execute Atmospheric_correction_V3.py
Find *_BP_FIX_SMILE_FIX_AC_ACHEAT.hdr, Find *_BP_FIX_SMILE_FIX_At_Comp.bil
Execute produce_wv_quality_mask_V2.py
Execute image_swath.py
Launch ImageMagick commands
Launch move, copy and delete files
Direction of execution
Hyperion ATBD 29
Figure 12 shows the execution order within the perl module. Most of the input files for the python modules are located using the find command in bash. Some files are intrinsically named using the Hyperion file base name (this is the .L1R file with the .L1R stripped off) and whatever extension will be assigned to a new file by the various python modules. If there are multiple files in a directory of a particular type (such as *_BP_FIX.L1R) then the processing could become unstable or fail as some modules may just select the first file or try to run a second process. The perl script performs no error checking so it’s a good idea to try to get this right. In practice when this is used with the iVEC HPC system this script is copied into a directory where the L1R archive has been untarred and unzipped. In such cases there are exactly the required files in the directory. The Mod90_5.2.1.exe runs the MODTRAN5 radiative transfer code. This takes the tape5 files created by the Create_tape5_files.py module. The MODTRAN RT code generates a number of output files for each run. The tape7sc files are used by the Make_final_lookups.py and Calculate_wv_V2.py modules. The Launch ImageMagick commands box referrers to a number of bash commands which produce an RGB swath image from the output of image_swath.py module. The final command box also represents a number of bash commands. After all of the processing is complete a number of files are tarred and zipped to be copied into sub directories under an output directory. The script checks to see if these directories exist first and if not then the sub directories are created. Two archives are created that contain 1.) .L1R file in ENVI BIL format, .hdr file, .AUX file, .MET file and the quicklook.png, 2.) The reflectance product as an ENVI .bil file, the water vapor product, a header file for each and the quicklook image. The HDF files are copied without alteration. Once the files are created and copied elsewhere, the working directories are deleted. As stated previously, all of the python modules can be run independently as long as the modules have access to the correct files. If there were previously enhanced files where bad pixels, smile and other corrections had been done then you need only run the modules that retrieve water vapour and the atmospheric correction module. If you don’t wish to produce quicklook images and the quality mask then only run up to the atmospheric correction module. This code has been run on an Apple iMAC and the linux-‐based epic system based at iVEC. The iVEC processing has taken less than 30 min per Hyperion scene for a majority of the scenes. If a conservative number of processes, say 20, were run on a High Performance Computing system it would possible to process the entire archive in just over a day. For this work the workflow was a bit more hands-‐on so the processing took 3 days. Some processes failed when there were errors in the .MET file. These were generally errors of omission with spatial coordinates missing from the file. The formatting of some of the numbers changes from file to file, which also caused issues. These errors were identified and fixes for them are programmed into the code. Other files that are not in the current archive may have other problems that have not been encountered. If a file fails to process, examine the .MET file first to see if it has a format that differs from the expected format.
Hyperion ATBD 30
Conclusion This document provides the theoretical basis and algorithm descriptions for a number of python modules. It also provides information on the workflow structure required to link these modules into the correct processing chain. The code described herein has been used to process all of the 1276 files currently in the AusCover Hyperion database to a surface reflectance product. The processing is not as extensive as the multitude of steps as suggested by Dr. David Jupp but should provide an adequate surface reflectance products where the data are altered as little as possible. If in the future further processing modules are developed it will be easy to slot them into the current workflow structure. The relatively short time period required to re-‐process the data makes this an achievable task. Bibliography Berk, A., Anderson, G., Acharya, P., Shettle, A., 2011, “MODTRAN®5.2.1 USER’S MANUAL”, Spectral Sciences Inc., Air force Research Laboratory CSIRO, 2011, “Information from the CSIRO Data Users Workshop”, received 2011 Datt, B., McVicar, T., Van Neil, T., Jupp, D., Pearlman, J., 2003, “Preprocessing EO-‐1 Hyperion Hyperspectral Data to Support the Application of Agricultural Indexes”, IEEE Transactions on Geoscience and Remote Sensing, Vol. 41, No. 6, pp 1246 -‐ 1259 Datt, B., Jupp, D., 2004, “Hyperion Data Processing Workshop: Hands-‐on processing instructions”, CSIRO Earth Observation Centre Guanter, L., Richter, R., Kaufmann, H., 2009, “On the application of MODTRAN4 Atmospheric Radiative Transfer Code to Optical Remote Sensing”, International Journal of Remote Sensing, 30 (6), pp. 1407 -‐ 1424 Jupp, D., Datt, B., McVicar, T., Van Niel, T., Pearlman, J., Lovel, J., King, E., 2003, “Proceedings: SPIE Third international Asia-‐Pacific Remote Sensing symposium”, Image Processing and Pattern Recognition in Remote Sensing, Vol. 4898, pp 78 – 92 Pearlman, J., Barry, P., Segal, C., Shepanski, J., Beiso, D., Carman, S., 2003, “Hyperion, a Space-‐Based Imaging Spectrometer”, IEEE Transactions on Geoscience and Remote Sensing, Vol. 41, No. 6, pp 1160 – 1173 Richter, R., Schläpfer, D., Müller, A., 2011, “Operational Atmospheric Correction for Imaging Spectrometers Accounting for the Smile Effect”, IEEE Transactions on Geoscience and Remote Sensing, Vol. 49, No. 5, pp 1772 – 1780 Rodger, A.P, 2009, “Getting to Grips with MODTRAN4’s Tape7 output Files”, CSIRO Exploration and Mining, private communiqué
Hyperion ATBD 31
Rodger, A.P, 2011, “SODA: A new method of in-‐scene atmospheric water vapour estimation and post-‐flight spectral recalibration for hyperspectral sensors, Application to the HyMap sensor at two locations”, Remote Sensing of Environment, 115, 536 -‐ 547 Schläpfer, D., Borel, C., Keller, J., Itten, K., 1998, “Atmospheric Precorrected Differential Absortion Technique to Retrieve Columnar Water Vapour”, Remote Sensing of Environment, 65, pp 353 – 366 Ungar, S., Pearlman, J., Mendenhall, J., Reuter, D., 2003, Overview of the Earth Observing One (EO-‐1) Mission”, IEEE Transactions on Geoscience and Remote Sensing, Vol. 41, No. 6, pp 1149 -‐ 1159