Custom Query (432 matches)
Results (145 - 147 of 432)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#168 | fixed | Overflow handling in azspec | mggr | mggr |
Description |
[Issue began 5/June/2008, split out from #133 18/June.] While fixing the FODIS processing (#133), Bill noticed that the overflow value he was looking for was 4096 but should actually have been 4095. In fixing this, he has unearthed a large number of overflows in captured Eagle and Hawk imagery. In Hawk, which shifts the whole frame out of the CCD at once, these overflows will only affect the data at the bandpixel that has overflowed. The only fix required is to mark the bad pixels and to provide info to the flight crew to allow them to set camera values appropriately. In Eagle, the CCD shifts the image out a line at a time, which means light continues to accumulate during the shifting procedure. This additional light is removed by "frame smear correction", where a proportion of the light is removed from each pixel, accumulating as the shifts progress through the frame (begins at the red end of the spectrum and proceeds to the blue end). However, if a pixel overflows, it is no longer possible to estimate the proportion of light to remove from the next pixel (as it will be unmeasured due to pixel saturation). |
|||
#171 | fixed | Support: 25/Jun/2008, Thomas Ruhtz, NL08/01 | mggr | mggr |
Description |
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 |
|||
#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:
|