Changes between Version 1 and Version 2 of Processing/PixelSize

Timestamp:

Feb 4, 2008, 7:04:37 PM (16 years ago)

Author:

mggr

Comment:

--

Processing/PixelSize

@@ -9 +9 @@
 || > 8000 ft           || 5m   ||
 
-Note that you should look at the azgcorr output to get a good idea of what your actual pixel sizes are, e.g.:
+== More info ==
+
+To get a (still approximate) "best" pixel size, run through azgcorr once and there's a block in the azgcorr output:
 {{{
-...
-
 Pixel spacing stats... along line...
-   centre     min: 4.45 max: 5.04 ave: 4.64
-   port       min: 0.35 max: 32.31 ave: 6.48
-   starboard  min: 0.56 max: 35.08 ave: 6.77
-   across line centre (pix 238): 4.11
+  centre     min: 3.67 max: 3.79 ave: 3.74
+  port       min: 3.01 max: 18.31 ave: 8.50
+  starboard  min: 1.20 max: 14.58 ave: 5.08
+  across line centre (pix 256): 3.68
 }}}
 
+You need to pick a pixel size that is close to the "across line centre" value, but smaller if the terrain is high up and larger if you get a lot of tearing of the image at the edges.
+
+== Best pixel size procedure ==
+
+To get the best pixel size, start with a large pixel size (5 or 10m) and process just a few bands for speed.
+
+Reduce the pixel size progressively until you stop getting more detail out of the smaller pixel sizes or the edges start tearing.
+
+If you find that you're getting tearing at the edges but you still want to make the pixel size smaller to increase detail, you can also increase the interpolation value used by azgcorr - use the -g flag, which takes x and y direction values, eg:  azgcorr ... -g 5 5. This represents the maximum multiple of the pixel size across which it will interpolate the value, so if you've got 5m pixels then the above would interpolate across a no-data area of 25m. The default for this is 4 in both directions. 
 
 ---------
-Add notes on:
- * -g interpolation
- * different sensor types and characteristics
-   * specim non-square pixels (along track)
+
+== Sensor specific notes ==
+
+As regards pixel size, the largest effect is the movement of the aircraft during image acquisition.  All sensors take some time per scan accumulating light and, during this time, the aircraft will move forwards.
+ * ATM is a scanning sensor, so the aircraft will move forwards as the scan proceeds, resulting in a 'tilted' scan.  This is accounted for in the processing.
+ * The effect on CCD sensors is that pixels will be longer along-track than across-track
+ * Additionally, the Specim instruments have pixels that are inherently non-square (along track) due to the design of the slit.
+
+---------
+
+Detailed email from Bill on pixel sizes:
+{{{
+Level 1 pixel "size" would be the dimensions of the solid view vector
+from the sensor to the intersection with the ground. So although you
+have a pixel FOV it's in radians. The actual ground sizes required the
+navigation and DEM to convert this to metres on the ground. The table
+listed from the nav pre-processing part of azgcorr only uses the
+position info not the sensor parameters. These are made use of in the
+calculation of pixel coordinates, and there is no listing from that
+section of the program.
+
+So in a way, if one is pedantic,  "Pixel spacing stats" is a misnomer -
+it perhaps should be retitled: "Scan ends and centre spacing"!. Also,
+throughout, "line" is the flight line and across line would be scan
+direction but you have to allow for the heading - track ie drift angle.
+Also for the ATM (rotating mirror scanner)  the scan will not be a
+straight line as it takes a time to acquire during which the aircraft
+will have moved and CCD instruments have the integration period to take
+into account, so they can end up looking at long streaks in the along
+flight line direction; at typical flight speeds the plane does 6cm per
+msec, so if the integration is 30msec  you have got 1.8 m motion
+already! It's even more complicated because the Eagle and Hawk appear to
+have an along line IFOV twice as large as the across line. I can let you
+have a table of pixel dimensions at different heights, speeds and
+integration if you are interested.
+
+The spacing is referring to that of the scans, projected to spheroid
+using the aircraft spheroid height as given by the gps, ie they do not
+take into account the DEM. Think of a view triangle from the sensor to
+the ground, where the apex angle is the total field of view, the sides
+are the peripheral view vectors and the base side is approximately the
+projection on the spheroid of the scan; the height of the apex is the
+aircraft height above the spheroid.
+
+So centre, port and starboard refer to the distance apart from one scan
+to the next of the ends and centre of the scans after 3D transformation
+using the attitude and aircraft 3D position. The "across line centre"
+size is obtained by using the centre pixel instantaneous field of view
+and the average flight height for the line; again above the spheroid; so
+in a way is a more representative size than the scan spacing.
+
+This is not intended to be actual pixel size on the ground as that would
+need to be obtained after using the DEM, if present. This is only meant
+as a guide to choose an output pixel size. Because of this one would use
+a pixel size close to the "across line centre"; but you would reduce the
+size if the ground was high or increase the size if the averages at the
+scan edges show a lot of attitude opening of the scans.
+
+You have to also remember that the area viewed by a single pixel is not
+a clear cut-off; the pixel's point spread function is assumed to be
+gaussian, so it "sees" into the surrounding ones.
+}}}