Azspec-processed level 1b hawk data does not appear to be correct - it contains large anomalous spikes in some bands, seemingly correlated to very low data values. Eg from Nigg Bay line 3:

Compared to Caligeo spectrum from same pixel:

Could be underflowing, but would expect a much higher value for the spikes (~65k) in this case. Might still be underflowing and then changed by maths in azspec though.

Note extended from ticket #106, but separate to Hawk noise issue

Some ATM lines for IPY have bad bands marked for some lines. However, the bad parts seem to correlate with areas where there is bright sunshine shining on white snow - in other words where the value is going to be pretty close to max. It's possible either this is incorrectly causing it to be classified as bad, or else that the max value is itself being used to mark bad data.

Eg. Green Box line 1:

Ricardo contacted us yesterday with:

  Recently you offered your help with any general Eagle/Hawk/CASI/ATM processing issues and we would like to consult about our Eagle/Hawk data processed with azgcorr. As you maybe are aware, Doñana (SW Spain) was overflown March last year and we have been using azgcorr to produce Level 3 geocorrected data, and able to apply atmospheric corrections with the great help of Andrew Wilson from CEH. However, to manage the huge files of the geocorrected Level 3 data at full spatial and radiometric resolution is still a pain because of file size, specially in cases in which we have lots of ground-thruth positions in different flight-lines (our main EUFARNet aim and goal is to map 2 allien plant species).

   That is why we are also trying to obtain IGM files for ENVI (X and Y coordinate files that help in overlying ground-truth areas, more info at http://www.ittvis.com/services/techtip.asp?ttid=3816), and this is why we are testing
the possibility to do it with PARGE since AZGCORR has not this option (although the calculations must be embedded somewhere in the code, during the geocorrection process, as Andrew Wilson indicated). This might simplify the process of overlaying ground-truth on flight-lines before applying any geocorrection to the final product (mostly classification maps). Would it be possible to incorporate such an option on AZGCORR processing?

As this is not the only project in which we are working, and we are not experienced hyperspectral data users, it is taking us longer than we would have liked to analyse the data.

The IGM files appear to be ENVI's method for specifying per pixel coordinates. This is the same issue as #109.

Replying to Ricardo with the info we have on this, and the current tentative plan for this to be implemented pending availability of development time. Raising the importance of that issue too.