Changes between Version 3 and Version 4 of Procedures/hyperspecprocessing

Timestamp:

Feb 13, 2012, 11:17:32 AM (13 years ago)

Author:

mark1

Comment:

--

Procedures/hyperspecprocessing

@@ -49 +49 @@
 '''Calibrate FODIS if Eagle data'''
 
- The FODIS is blah blah blah <insert FODIS text>. This is calibrated in the same way as the other raw data. When calibrated, the FODIS pixels for the same scan line are averaged together to further reduce random noise.
+ The FODIS collects down-welling light, and is stored on the first 71 pixels of the Eagle CCD. This is calibrated in the same way as the other raw data. When calibrated, the FODIS pixels for the same scan line are averaged together to further reduce random noise.
 
 '''Insert Missing Scans'''
@@ -58 +58 @@
 
  A mask file will be created at the same time that the radiometric calibration is applied. This is a file of the same dimensions as the raw data file that contains the status of each calibrated pixel. The values in the mask file are as follows:
- 0 - good data
- 1 - underflown data - the raw value after normalisation is less than 0.
- 2 - overflown data - the raw value is equal to the maximum (4095 for Eagle, 16383 for Hawk).
- 4 - bad pixel - usually refers to a Hawk CCD pixel that is considered untrustworthy. Is also used for first 2 pixels of band 1.
- 8 - Smear affected - a longer wavelength Eagle band has overflown causing the smear correction for this pixel to be incorrect by an unknown quantity.
- 16 - Dropped scan - a missing scan has been detected and inserted here.
+
+ 0 - good data \\
+ 1 - underflown data - the raw value after normalisation is less than 0. \\ 
+ 2 - overflown data - the raw value is equal to the maximum (4095 for Eagle, 16383 for Hawk).\\ 
+ 4 - bad pixel - usually refers to a Hawk CCD pixel that is considered untrustworthy. Is also used for first 2 pixels of band 1.\\ 
+ 8 - Smear affected - a longer wavelength Eagle band has overflown causing the smear correction for this pixel to be incorrect by an unknown quantity.\\ 
+ 16 - Dropped scan - a missing scan has been detected and inserted here.\\
 
 '''Flipping data and writing'''
 
- The calibrated data, FODIS and mask files are stored in ENVI BIL format. Prior to writing out, the image data and mask data is reordered. The Eagle data is "flipped" spectrally such that the first band is the lowest wavelength and the last band is the highest (i.e. such that wavelengths are ordered blue to red). The Hawk data is "flipped" spatially such that each scan line is reveresed (i.e. pixel 1 becomes pixel 320). This is done because the Eagle and Hawk are mounted backwards to each other and flipping allows targets to be more easily compared between the two sensors data. 
+ The calibrated data, FODIS and mask files are stored in ENVI BIL format. Prior to writing out, the image data and mask data are reordered. The Eagle data is "flipped" spectrally such that the first band is the lowest wavelength and the last band is the highest (i.e. such that wavelengths are ordered blue to red). The Hawk data is "flipped" spatially such that each scan line is reversed (i.e. pixel 1 becomes pixel 320). This is done because the Eagle and Hawk are mounted backwards to each other and flipping allows targets to be more easily compared between the two sensors data prior to geocorrection. 
 
 
@@ -78 +79 @@
 APL takes as input these SBET and real time navigation files, together with the calibrated image header information and uses a spline interpolation to get sensor position and attitude for each scan line. It also applies the given sensor boresight and lever arm offset values to the navigation data. 
 
-The Eagle and Hawk sensors can suffer from inaccurate timing of the order of ~0.1 seconds. This means that the navigation data and scan lines can be out of sync, which manifests itself as a "wobbly" image <link to wobbly image page>. This is currently corrected by eye at ARSF-DAN, processing using time offsets with accuracies of 0.01 seconds.
+The Eagle and Hawk sensors can suffer from inaccurate timing of the order of ~0.1 seconds. This means that the navigation data and scan lines can be out of sync, which manifests itself as a "wobbly" image. See [wiki:Processing/Corrections/Timing here] for an example. This is currently corrected by eye at ARSF-DAN, processing using time offsets with accuracies of 0.01 seconds.
 
 
@@ -85 +86 @@
 This stage of the hyperspectral data processing involves generating a per-pixel list of latitude and longitude values. This is currently only done at ARSF-DAN for quality control and to check the correct navigation syncing has been used. A Digital Elevation Model (DEM) is required to get accurate geocorrection information. The format of the DEM file should be an ENVI file (either BIL or Band sequential (BSQ)) with geographic projection in WGS84 latitude and longitude. The heights should be referenced against the WGS84 spheroid. This is because the GPS navigation is referenced in WGS84 latitude/longitude projection and all other inputs should also be given in this projection to allow direct comparisons. 
 
-For each pixel of the scan line, a CCD pixel-to-ground view vector needs to be constructed. This is made up from the sensor view vector <link to view vector page?> and the navigation attitude (which includes the boresight offset). This vector has origin at the sensor, which is given by the synced position since the lever arm offset has been applied. The vector is traversed from the origin until it intersects the DEM surface, at which point the latitude, longitude and height are recorded.
+For each pixel of the scan line, a CCD pixel-to-ground view vector needs to be constructed. This is made up from the sensor view vector and the navigation attitude (which includes the boresight offset). This vector has origin at the sensor, which is given by the synced position since the lever arm offset has been applied. The vector is traversed from the origin until it intersects the DEM surface, at which point the latitude, longitude and height are recorded.
 
-The geocorrection information is written out as a 3-band BIL file (refered to as an IGM file) where the bands are: longitude, latitude and height.
+The geocorrection information is written out as a 3-band BIL file (referred to as an IGM file) where the bands are: longitude, latitude and height.
 
 
 === Stage 4: Re-projection ===
 
-Prior to generating a mapped image it may be best to reproject the data into a more suitable projection, e.g. Transverse Mercator. APL makes use of the open source PROJ <link> libraries for doing reprojection. If the data is collected in the UK and wants to be in Ordnance Survey (OS) National Grid projection, then there is a grid-shift file available from the OS website which can be used with PROJ. Typically ARSF-DAN will use either the OS National Grid or Universal Transverse Mercator projection for quality control of the data. The output file has the same format as the previous stage - a 3-band BIL file.
+Prior to generating a mapped image it may be best to reproject the data into a more suitable projection, e.g. Transverse Mercator. APL makes use of the open source [http://trac.osgeo.org/proj/ PROJ]  libraries for doing reprojection. If the data is collected in the UK and wants to be in Ordnance Survey (OS) National Grid projection, then there is a grid-shift file available to [http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/OSTN02_NTv2_DataFiles.zip download] from the OS website which can be used with PROJ. Typically ARSF-DAN will use either the OS National Grid or Universal Transverse Mercator projection for quality control of the data. The output file has the same format as the previous stage - a 3-band BIL file.
 
 
@@ -109 +110 @@
 When all the flightlines for a project have been processed, the data are quality checked to ensure the correct navigation timing has been used. This consists of processing the data with various navigation timing offsets and examining each one for erroneous wobbles. When the image with the correct timing offset has been identified, this offset is recorded for future reference.
 
-When all timing offsets for all flightlines have been correctly identified the delivery can be created <link to delivery creation>. This is then checked <link> over by another individual to identify any possible errors before dispatch <link> to the end user.
+When all timing offsets for all flightlines have been correctly identified the delivery can be [wiki:Procedures/EagleHawkProcessing#Makingadelivery created]. This is then [wiki:Procedures/DeliveryChecking checked] over by another individual to identify any possible errors before [wiki:Procedures/EndUserDelivery dispatch] to the end user.