azgcorr's point cloud conversion function appears to have a problem with correctly detecting the UTM zone from a ULM LIDAR point cloud. Specifically, with a file like:

  472077.149175 30593792.77 4095708.38  131.27    87 30593792.77 4095708.39  131.31    87
  472077.149205 30593792.79 4095707.83  131.27    81 30593792.79 4095707.84  131.29    81
  472077.149235 30593792.82 4095707.10  131.30   100 30593792.82 4095707.12  131.34   100
  472077.150285 30593792.91 4095706.78  131.31   105 30593792.90 4095706.80  131.37   105
  472077.150315 30593792.89 4095707.31  131.26    84 30593792.89 4095707.33  131.30    84
  472077.150345 30593792.86 4095708.07  131.31    84 30593792.86 4095708.07  131.30    84
  472077.150375 30593792.82 4095708.87  131.46    89 30593792.82 4095708.87  131.47    89
                 easting     northing   height        easting     northing   height (last pulse)
               UTM zone 30 appended to easting coords
...

and running azgcorr -ELpt f1 x -d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 -e Str_287.first1000, you get:

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


DEM pre processing...

Initialised transform for point cloud to WGS84 geogs...

Projection and datum shift details initialised....
Spheroid name: WGS84
  semi-major: 6378137.00000  semi-minor: 6356752.31425  e^2: 0.006694380 1/f: 298.257223563
Projection name: UTM
  origin  lat: 0.0000  long (central meridian) : -0.0288
  grid coords at origin  easting: 500000.00  northing: 0.00
  scale factor: 0.99960000  hemisphere: north
Datum shift name: none

Initialised transform for point cloud WGS84 geogs to local datum and projection...

Projection and datum shift details initialised....
Spheroid name: INTERN
  semi-major: 6378388.00000  semi-minor: 6356911.94613  e^2: 0.006722670 1/f: 297.000000000
Projection name: UTM
  origin  lat: 0.0000  long (central meridian) : -3.0000
  grid coords at origin  easting: 500000.00  northing: 0.00
  scale factor: 0.99960000  hemisphere: north
Datum shift name: SING
  old spheroid name: INTERN
  semi-major: 6378388.00000  semi-minor: 6356911.94613  e^2: 0.006722670 1/f: 297.000000000
  dx: -87.0000 dy: -98.0000 dz: -121.0000 metres  sc: 0.000000  ppm
  rx: 0.0000 ry: 0.0000 rz: 0.0000 secs


old x: 593792.77 y: 4095708.38  z: 131.270 lat: 37.0028547 lng: 1.0253605
new x: 858150.51 y: 4102789.67 z: -12.422
old x: 593792.77 y: 4095708.39  z: 131.310 lat: 37.0028548 lng: 1.0253605
new x: 858150.51 y: 4102789.68 z: -12.382
old x: 593792.79 y: 4095707.83  z: 131.270 lat: 37.0028497 lng: 1.0253606

The first time the central meridian appears in the output, it is -0.0288 (should be -3). On subsequent runs, this number changes at random.

Specifying the meridian manually (e.g. azgcorr -ELpt f1 W003 -d7 0 -87 -98 -121 0 0 0 0 -mUTMZ 30 -e Str_287.first1000-nozone) appears to work. Rather oddly, it doesn't appear to matter if the UTM zone is stripped from the coordinates or not - the output is identical.

Contacting Bill to see if this is a bug or a misunderstanding on our part.

[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).

It would be useful if azgcorr could output some extra information on the mapping of points.

Peter Land was interested in level 1 ground coordinates per pixel.

Chris Hecker (#108) has requested per-pixel geocoordinates or per pixel view vector info for feeding into ATCOR, also presumably at level 1. He said ATCOR needed, as an input parameters for the atmospheric correction model, the viewing geometry and distance between plane and each pixel. This can be supplied either as:

• a geo lookup table (GLT) that defines a map coordinate of each pixel while still in image coordinates
• a scan angle file with the viewing vector for each pixel (azimuth angle, zenith, angle, height of plane).

Peter contacted Bill about it, who replied (1/May/2007) with:

The option to 3D output pixel coordinates, solar and sensor view
vector details and time are on the cards for Andrew's group to use
with Modtran, so in the not too distant future will be available.