Changes between Version 1 and Version 2 of Processing/PixelSize

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



  • Processing/PixelSize

    v1 v2  
    99|| > 8000 ft           || 5m   ||
    11 Note that you should look at the azgcorr output to get a good idea of what your actual pixel sizes are, e.g.:
     11== More info ==
     13To get a (still approximate) "best" pixel size, run through azgcorr once and there's a block in the azgcorr output:
    13 ...
    1515Pixel spacing stats... along line...
    16    centre     min: 4.45 max: 5.04 ave: 4.64
    17    port       min: 0.35 max: 32.31 ave: 6.48
    18    starboard  min: 0.56 max: 35.08 ave: 6.77
    19    across line centre (pix 238): 4.11
     16  centre     min: 3.67 max: 3.79 ave: 3.74
     17  port       min: 3.01 max: 18.31 ave: 8.50
     18  starboard  min: 1.20 max: 14.58 ave: 5.08
     19  across line centre (pix 256): 3.68
     22You 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.
     24== Best pixel size procedure ==
     26To get the best pixel size, start with a large pixel size (5 or 10m) and process just a few bands for speed.
     28Reduce the pixel size progressively until you stop getting more detail out of the smaller pixel sizes or the edges start tearing.
     30If 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.
    24 Add notes on:
    25  * -g interpolation
    26  * different sensor types and characteristics
    27    * specim non-square pixels (along track)
     34== Sensor specific notes ==
     36As 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.
     37 * 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.
     38 * The effect on CCD sensors is that pixels will be longer along-track than across-track
     39 * Additionally, the Specim instruments have pixels that are inherently non-square (along track) due to the design of the slit.
     43Detailed email from Bill on pixel sizes:
     45Level 1 pixel "size" would be the dimensions of the solid view vector
     46from the sensor to the intersection with the ground. So although you
     47have a pixel FOV it's in radians. The actual ground sizes required the
     48navigation and DEM to convert this to metres on the ground. The table
     49listed from the nav pre-processing part of azgcorr only uses the
     50position info not the sensor parameters. These are made use of in the
     51calculation of pixel coordinates, and there is no listing from that
     52section of the program.
     54So in a way, if one is pedantic,  "Pixel spacing stats" is a misnomer -
     55it perhaps should be retitled: "Scan ends and centre spacing"!. Also,
     56throughout, "line" is the flight line and across line would be scan
     57direction but you have to allow for the heading - track ie drift angle.
     58Also for the ATM (rotating mirror scanner)  the scan will not be a
     59straight line as it takes a time to acquire during which the aircraft
     60will have moved and CCD instruments have the integration period to take
     61into account, so they can end up looking at long streaks in the along
     62flight line direction; at typical flight speeds the plane does 6cm per
     63msec, so if the integration is 30msec  you have got 1.8 m motion
     64already! It's even more complicated because the Eagle and Hawk appear to
     65have an along line IFOV twice as large as the across line. I can let you
     66have a table of pixel dimensions at different heights, speeds and
     67integration if you are interested.
     69The spacing is referring to that of the scans, projected to spheroid
     70using the aircraft spheroid height as given by the gps, ie they do not
     71take into account the DEM. Think of a view triangle from the sensor to
     72the ground, where the apex angle is the total field of view, the sides
     73are the peripheral view vectors and the base side is approximately the
     74projection on the spheroid of the scan; the height of the apex is the
     75aircraft height above the spheroid.
     77So centre, port and starboard refer to the distance apart from one scan
     78to the next of the ends and centre of the scans after 3D transformation
     79using the attitude and aircraft 3D position. The "across line centre"
     80size is obtained by using the centre pixel instantaneous field of view
     81and the average flight height for the line; again above the spheroid; so
     82in a way is a more representative size than the scan spacing.
     84This is not intended to be actual pixel size on the ground as that would
     85need to be obtained after using the DEM, if present. This is only meant
     86as a guide to choose an output pixel size. Because of this one would use
     87a pixel size close to the "across line centre"; but you would reduce the
     88size if the ground was high or increase the size if the averages at the
     89scan edges show a lot of attitude opening of the scans.
     91You have to also remember that the area viewed by a single pixel is not
     92a clear cut-off; the pixel's point spread function is assumed to be
     93gaussian, so it "sees" into the surrounding ones.