Mark Danson has requested his Eagle and Hawk data from WM06/04 (Madrid, 2006 days 136 and 154) be reprocessed as previously offered.

Email from Mark:

Gary

On another point there was an offer some time ago to reprocess ARSF
Eagle and Hawk data from the Spanish Campaign in 2006. Having now looked
at these data and struggled to get sensible radiometric information it
would be useful to take up that offer - is it still open and how should
I proceed?

Thanks and hope all is well

Mark

Reply from Gary:

Hello Mark,
The offer is still open, we are very happy to re-processing of the Eagle and Hawk data from the Spanish campaign in 2006 (WM06/04; Madrid, 2006-136 & 2006-154). However, re-processing these data will be after the final block of data from the end of 2008 are processed. We will keep you informed of developments.
Best wishes
Gary 

Processing data in azspec and using the -dIc option to rescale dark frames seems to cause the data to be incorrectly radiometrically calibrated.

I've attached three screenshots. dIc_ex1.png shows spectral profiles for the rescaled flightline from both azspec (top) and CaliGeo (bottom). You can see that the azspec spectrum goes up at both ends, where the CaliGeo spectrum doesn't. The azspec spectrum also has values that are consistently about 600 higher than CaliGeo (discounting the edges of the spectrum, which as mentioned are much higher).

dIc_ex2.png shows spectral profiles from the second flightline, which did not require the dark frames to be rescaled. Azspec and CaliGeo are in very close agreement for this line.

odd_one_out.png is just for illustration - it shows all of the Eagle lines from that flight (as processed through azspec) overlaid. The first flightline (with the rescaled dark frames) is clearly visible as different - much whiter than the other lines.

This may affect any datasets from 2006, and some VOCALS data.

Related tickets: #218 #250

The use of -l in azspec produces a blank image if anything than a start line of 0 is used. The end line number does seem to produce the correct effect however.

Same problem also occurs in azatm (causes errors saying "scan jump from: 0 to 191119 scan : 191119 rejected"). Same option in azcas2 seems to work correctly.