If you use the -cuo option in azatm to change the values it's supposed to set overflowed and underflowed pixels to, it doesn't seem to have an effect - always sets underflowed pixels to 0 (even if told to set them to ffff) and always says:

************* radcal underflow and overflow fill values changed ********
      under : 00000  = 0     over: 00000  = 0

...in azatm output, regardless of what values are entered for the under/overflow (tried with 0 fffe and ffff ffff).

Arose from testing on #115

From Chris Hecker (support ticket #42):

Since all our datasets are in ED50, I was trying in a next step, to get
that working. However, azgcorr seems to have troubles with the -d7
option. I use the following statement (without DEM at the moment):

azgcorr -1 h153131b.hdf -3 h153131b_out_noDEM_ED50.hdf -BIout \
-d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 \
-in -p 2 2 -bl 100 -1 \
-v > h153131b_out_noDEM_ED50.txt

This should give me UTM Zone 30 for ED50 mean. However, the -v output to
the txt file shows that it uses Datum Shift type "Dutch" which is made
for RD reference system (not UTM at all) with Bessel ellipsoid etc, so
something different.

Confirmed this does the same for me, example output:

-----------------------------------------------------------------------
azgcorr  -- ver: 4.8.3-lin Jun 12 2007   (C) Azimuth Systems UK 1996, 2007


Note: NO DEM is being used which means that if significant topographic
      variation is present the geocorrected image will be unsuitable for
      accurate georeferencing against map or vector data or for mosaicing
      with adjacent lines, see User Guide for more details

data recorded in year: 2006  date: 02/06/2006
CCD type [3]: SPECIM sensor details and data

HDF level 1 input file: h153131b.hdf
No CApsfov table on hdf - using default optic details

Scanner: CCD image (CAimage) pixels: 320 lines: 3336 bands: 237
  config: Specim HAWK  SWIR
  view angles port: -11.8526 star: 11.8526

Navigation...
  navigation spheroid: user  map projection spheroid: INTERN
  datum shift type: DUTCH  map projection: UTM
...

Contacting Bill to see if this is a misuse/misunderstanding on our part or a bug in the option-reading/display code.

Karl reports that if he geocorrects his data using azgcorr, any ENVI header file generated (either automatically because the file size went over the HDF limit, or manually using azexhdf -Be) reports the projection as UTM zone 30. I have duplicated the problem using one of the boresight flights, will contact Bill about it.