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)

Contacted via Peter Purcell. Thomas would like some raw data for quick feedback on the EUCAARI flights in order to assist with VOCALS preparations.

Hi Peter,

Hugh did agree to work together on the Vocals and eucaari data analysis and I
will ask him further if he agrees to our participation during the campaign.
We are going to write a proposal and would like to include some data of the
eucaari campaign. The proposal will focus on the analysis of remote sensing
data and aerosol and cloud products. We can put in some funding of our
participation at Vocals if Hugh agrees on that.

I did discuss with Phil during the campaign the possibity to get the raw data
on a harddisk and it should be the easiest way to have a quick look at the
data for our proposal. The linux quick look tool would help a lot as well. I
only have some older software of the Aisa system and dont know if it works
with the Eagle/Hawk data. Later on if the prosessing is finished at PML we
can discuss the processing of the data in more detail. I think this will be
the case during JRA4 anyway. Who is the contact point at PML for the data
processing or whom should I contact in case of questions regarding the
procedures, calibration coefficients etc.

Thanks a lot

Thomas

Dear Ivana,

My name is Elena Prado and I am a user to azgcorr. I have some questions for you,

I try to geocorrect CASI images to achieve L3 product. The images were
acquired over Guadalajara (Spain).

Datum transformation

I am using azgcorr with the option of 7 parameters for datum transformation;
the parameters are specially adapted to the flight zone. But when I check the
results, the images have an offsets in coordinates (offset in Xutm = 104
offset in Yutm = 132).

I know that the images are synchronized with the navigation data because the
effects of the aircraft movement have been removed correctly. 

The offset in Xutm fit with the difference between WGS84 and European Datum
1950 so I am not sure that the azcorr makes the transformation.

I send you the azgcorr command line:

> azgcorr  -p 3.5 3.5 –bl 45 15 5 -1 –d7 0 131.032 100.251 163.354 -1.2438 -0.0195 -1.1436 -9.39 –mUTM -3 –eh /MDT25_IGN_GUADA_ED50_3m_he.txt –es NO –ua 0 0 -0.465 –ut -59.995 -1 /c154011b.hdf -3 /c154013_ed50.hdf

-p 3.5 3.5 : pixel size 3.5 meters
-bl 45 15 5 -1 CASI bands to georeference 45/15/05
–d7 0 131.032 100.251 163.354 -1.2438 -0.0195 -1.1436 -9.39: seven parameters for datum transformation
-mUTM -3 : UTM projection zone 30. (central meridian longitude -3)
-eh : DEM file in UTM H30 ED50 and ellipsoidal height
-es NO : no geoid undulation
-ua 0 0 0.465 : offset in heading to apply the meridian convergence
-ut -59.995: offset  to correct the synchronization between image and navigation data

Can you help me with the Datum transformation?

ENVI header

I use the azexhdf to get a Envi header.

> azexhdf –h /c154013_ed50.hdf –Be /c154013_ed50.bil

I get a BIL format image with this command line and in other
folder (I don’t know why azexhdf doesn’t write in the same folder)
get another file P9.hdr with the Envi header. But the map info in
the header is not correct. The datum of the L3 image doesn’t appear
in the header file and the coordinate of the header is the SW image
corner coordinate instead of NW image coordinate that ENVI needs.

Map info = {UTM, 1, 1, 562233.00, 4518052.00, 3.50, 3.50, 30, North}

Do you know how I can solve this?

Image line start – line end

I detect that the data have a des-synchronization between the image
and navigation data, this time offset is 59 seconds more or less 
This time is equivalent to 909 lines from the first line in the image
L1b. I think that with this scan timing offset (-ut -59.995) the
synchronization is ok, so I don’t know how use the information about
the scan line (start / end) number information.

Can I do without these??

Data extracted from c154011b.hdf
MIsscan: 248
MIsescan: 6009
NVscnum 248 -> 6009
CAsscan: 248
CAescan: 6010
COsscan: 248
COescan: 4205
COscans: 3958
 
Thanks you very much,

Elena Prado Ortega
<Contact details removed, see internal contact details page>
MailScanner has detected a possible fraud attempt from "correo.uah.es" claiming to be http://www.geogra.uah.es/teledeteccion-ambiental
___________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o CONFIDENCIAL. Si vd. no es la persona a quien se dirige este mensaje, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it.