Custom Query (419 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (97 - 99 of 419)

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

#109 fixed Output of ground coordinates in azgcorr mggr mggr
Description

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.
#289 fixed Orthorectification and seamlining of RCD photos mggr mggr
Description

People at RSPSoc strongly expressed a wish to have orthorectified photos. This is a huge chunk of work and very manual to do the full process using the Leica workflow. Other workflows may improve this, e.g.

similar helped a lot

  • John Stevenson managed some of this with GRASS

ARSF-DAN agreed to investigate this as a background, low priority task. In particular, it may be worth considering a halfway house (tiepointing & colocating, which can be automatically done, but not seamlining, which is intensively manual at present).

Note: See TracQuery for help on using queries.