Custom Query (419 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (40 - 42 of 419)

Ticket Resolution Summary Owner Reporter
#108 fixed Support: 28/Mar/2008, Chris Hecker, WM06/06 mggr mggr
Description

New contact from Chris with some atmospheric correction questions (note #42 for previous support)

Hi Mike;
 
after a few months of radio silence, I have a question for you again! ;-)
 
I am wanting to do atmospheric correction on the 2006 Mojacar Eagle and Hawk data with ATCOR4 ( http://www.rese.ch/atcor/atcor4/index.html). For that I need to also input
- a sun elevation and sun azimuth file (which I should be able to do with some freeware software)
- a scan angle file  with the viewing vector for each pixel (azimuth angle, zenith, angle, height of plane).
 
Gary mentioned that you may be the person best suited to judge which workaround or tool from the user community is available for that. He mentioned that Matt Disney from London had retro-engineered the info in the past for BRDF studies.
Do you know anything about that and are these tools(?) available?
 
 
The other question is about the metadata info in the hdf file.
 
I presume that folder "Navigation" contains info from the plane's IMU (NVhead, NVpitch NVroll), and GPS (NVlat NVlng NVhgt)
 
and that the folder "Coordinates" contains info from a ?second IMU (COhead, COpitch COroll) and a ?second GPS (COlat, CO lng, COhgt) which are positioned near the instruments.
 
Is that correct? What do the values in COqual represent? Do you have a document that explains the different tags in the hdf file? That would be ideal.
 
 
Thanks and cheers from Holland,
Chris 

From: Chris Hecker
Sent: Friday, February 22, 2008 4:46 PM
To: 'Gary Llewellyn'
Subject: Info and GLT

Hi Gary;
I have a "couple" of questions. Maybe some are to be forwarded to Phil or somebody else from the processing team.
 
a) did you get the DGPS data from the ftp site? Please let me know when you manage to download the stuff so I can remove it.
b) the Ethiopia SIM card that you gave to me expires in April. I presume you wont need it back. Otherwise let me know.
c) is there a location on the ARSF site where we can see processing progress? I was also wondering if I could find the updated sortie briefs or a shape file that has the final coordinates of all areas flown in the Ethiopia campaign. An ethiopian student was asking me since he wanted to know in what areas hyperspectral data will become available later on.
 
d) this is maye a tricky one. I am looking at the data from 2006 Spain (Mojacar, PI  = Teeuw). I had eventually figured out the geomcorrection with azgcorr. 
Now for the atmospheric correction we want to use ATCOR 4 (programmed by Rolf Richter  DLR and I think Iten from Zuerich). One of the input parameters for the atmospheric correction model is the viewing geometry and distance between plane and each pixel.
this can be supplied either as:
- a geo lookup table (GLT) that defines a map coordinate of each pixel while still in image coordinates
- a scan angle file  with the viewing vector for each pixel (azimuth angle, zenith, angle, height of plane).
 
I looked in the supplied hdf file that accompanies the BIL files. From the coordinate info I should be able to extract the vector for each pixel, but its a lot of work to calculate that.
Do you have a tool that could do this for me? In principle one of the modules of the azgcorr suit has to do a similar calculation for the geocorrection. Is it possible to extract this info ourselves or get it from one of you?
 
What are other people doing about the atmospheric correction of the Eagle and Hawk data? Have you heard any expereinces from other research teams?
#102 fixed Support: 28/Jan/2008, Johanna Breyer (Pete Bunting), GB06-11 mggr mggr
Description

Following an updated azgcorr, Johanna is now working on using external BIL files (note previous support ticket #56 for background).

We have been trying to run azgcorr with a BIL file as we have now  
atmospherically corrected the CASI data (through FLAASH in ENVI, with good
results), but the command is not running
as expected. In the PDF documentation it states that we should use the  
-Bi command to specify the location of the BIL file and the -B command  
to specify its parameters. The -B command is stated as having 5
parameters:

option:
  -B  b t s o f

  BIL or BSEQ file content details
b = total bands on file
t = number type on file, 0= uint16, 1= float32
s = scale
o = offset to convert B file values for geom correction and saving as
uint16, v = p * s + o
f = &#64257;ll value for bad pixels; good pixels are < f

  if f = 0 the default values of 0 and 0xffff (uint16) or 10e30
(&#64258;oat32) are assumed
requirement:
  MUST be used if -Bi or -Bs are useddefaults:
  b NONE; s = 1.0; o = 0.0

When we execute the following commands (it works correctly without the  
-B and -Bi) we get the following error message:

./bin/azgcorr -v -mUK99 ./misc/osgb02.cgrf -e ../DEM/
vrynwy_dem_2m_ascii.txt -ed 1 8165 7530 291585.9219 314915.0528
307913.9219 329973.0538 2 -p 2 2 -1 ./lev1/c219011b.hdf -3 ./lev3/ 
c21013a.hdf  -B 15 1 1.0 0.0 0  -Bi ./lev2/c219012a_refl

-----------------------------------------------------------------------
azgcorr  -- ver: 4.8.7-lin Jan  2 2008   (C) Azimuth Systems UK 1996,  
2008


** parameter: ./lev2/c219012a_refl  does not start with:  -
**     and may be incorrect or out of sequence


After 'playing' with the commands experimenting with the order,
although stated in the documentation it is unimportant, we found that  
when an extra parameter (6 rather than 5) is added to the -B command   is
attempts to run but now fails with the following error.

./bin/azgcorr -v -mUK99 ./misc/osgb02.cgrf -e ../DEM/
vrynwy_dem_2m_ascii.txt -ed 1 8165 7530 291585.9219 314915.0528
307913.9219 329973.0538 2 -p 2 2 -1 ./lev1/c219011b.hdf -3 ./lev3/ 
c21013a.hdf  -B 15 1 1.0 0.0 0 0  -Bi ./lev2/c219012a_refl

-----------------------------------------------------------------------
azgcorr  -- ver: 4.8.7-lin Jan  2 2008   (C) Azimuth Systems UK 1996,  
2008

data recorded in year: 2006  date: 07/08/2006
CCD type [1]: CASI scanner details and data

HDF level 1 input file: ./lev1/c219011b.hdf
CCD CApsfov table from hdf file with: 512 entries
Image input BIL/BSEQ file: ./lev2/c219012a_refl
?? warning: BIL/BSEQ file size is not consistent with HDF details
?? expected size (from HDF): 15665152 bytes, actual size (BIL/BSEQ):  
117488640 bytes

Could you confirm the commands and their parameters or is there
something we are obviously doing wrong?
#172 fixed Support: 26/June/2008, Chris Hecker, WM06/06 + ET07/05 mggr mggr
Description

Chris contacted us with a lot of complex questions. Going to link full emails here rather than precis.

Hi Gary
I am currently working on the Eagle / Hawk data from the 2006 Campaign to Mojacar, Spain (WM06-06, PI: Teeuw, 2 June 2006), also as a testcase for the Ethiopia data.
I am using ATCOR-4 for airborne data for a model based atmospheric correction. while doing so I noticed artifacts that give troubles. I remember that the first year's data gave lots of headaches and was wondering if you knew about the symptoms I am getting and if you may have a workaround / solution for them. I put some screendumps in a *.ppt file for you.
 
Sensor Saturation
In some of the brighter areas of flightline 13, I notice some strange behaviour (it may be in other places as well, but I first noticed it in flightline 13, since our calibration sites are in that line). The Eagle spectra look OK as of about 0.7 micron. wavelengths shorter than that show a strong trough in their reflectance spectra. Slide 1 shows the spectra we recorded on the ground (in gree) and the Eagle spectra (in yellow and orange). It looks like the detector saturated and the data wrapped around when it reached the end of the ?sensitivit or long integer range. I checked the hdf file but couldnt really find any indication on which pixels had saturated during acquisition.
 
Here some questions:
- Was sensor saturation a problem that year?
- Can we get a mask that shows pixels that reached the saturation level (or close to saturation level) so we can mask them out. Or alternatively, the original DN values before they were changed to scaled radiance values.
 
Wavelength calilbration
The eagle and hawk hdf files come with central wavelength and width of each band. When I use that for the atmospheric correction, I get clear artifacts that show that there is a wavelength accuracy problem. slide2 shows a hawk spectrum with derivative looking artifact at 1.14 and also a general shift of the image spectrum towards longer wavelengths as compared to fieldspectra (green; for example alunite spectral feature at 2.2 looks shifted).
- are there any spectral response curves for individual detectors?
- is anything known about the shape of the response curves?
- can we assume that the widths of bands as listed in the hdf file is a fwhm for a gaussian shaped response curve (as an approximation)
- is there a newer wavelength calibration file than the one that was used then?
 
Spikes or steps
spectra often show a step around 0.688 microns and some spikes / noise at 0.860 (see slide 1).
- Is that related to an internal change to a different detector array?
- anything that can be done to correct for it?
 
 
Radiometric accuracy
radiance values in general look a bit lower than ground spectra with appropriate looking atmospheric correction. That's more an observation than a problem, since we can correct for that easily.
 
Actually, if I look at the figure 2c in the data_quality-2007.pdf , it looks to me like there is not only a radiometric shift between Eagle and Hawk but also a 50 nm wavelength shift. Sounds like a lot though, so not sure if that is possible.
 
Greets from Holland,
Chris

Summary of actions required:

  • generate 2006 overflow info and masks for Chris' projects (requires 2006 data)
  • notify with results of 2008 July calibration (wavelength and radiance) info when they become available
  • info on changes made to the setup of the two sensors between 2006 and 2008 (fov and nr of pixels) (speculated on this)
  • pass on copies of relevant CCD datasets if and when we get them from Specim (#173)
Note: See TracQuery for help on using queries.