8.20. Pleiades

ASP supports the 1A/1B and NEO satellites from Airbus Pleiades. For NEO, see Section 8.20.3 for additional notes. ASP also supports the Pleiades ortho products, if the projection was done on a surface of constant height (Section 8.20.4).

The Airbus Pleiades data have both an exact linescan camera model and an approximate RPC model (Section 8.18). These are stored in separate files. The names for these start with “DIM” and “RPC”, respectively, and end with “.XML”. ASP supports both kinds. The USGS CSM library (Section 8.11) is used for linescan models.

See Section 8.20.5 if the input images arrive in multiple tiles. See Section 16.39.9 for an example of solving for jitter for these cameras.

8.20.1. Bundle adjustment and stereo

If desired to process a Pleiades triplet, bundle adjustment (Section 16.5) is very recommended before stereo. It should be run as:

bundle_adjust -t pleiades --camera-weight 0 --tri-weight 0.1 \
  <images> <cameras> -o ba/run

Then, pass --bundle-adjust-prefix ba/run to parallel_stereo in all examples further down.

With the exact models, the stereo command is:

parallel_stereo -t pleiades --stereo-algorithm asp_mgm  \
    --subpixel-mode 9                                   \
    left.tif right.tif left_exact.xml right_exact.xml   \
    results/run

See Section 6 for a discussion about various speed-vs-quality choices for stereo.

For the RPC model the option -t rpc should be used and the correct camera files should be passed in. If the -t option is not specified, it will be auto-guessed based on the content of the camera files provided as inputs.

For Pleiades exact linescan camera models the atmospheric correction and velocity aberration corrections ([NC66]) are disabled. This ensures that the exact and RPC camera models agree (see below).

ASP supports running stereo with mapprojected Pleiades images (Section 6.1.7). All input images must be mapprojected at the same resolution (which is comparable with the ground sample distance). The same camera models must be used for mapprojection as for stereo, so one should not mix the exact and RPC cameras.

Example:

 proj="+proj=utm +zone=13 +datum=WGS84 +units=m +no_defs"

 mapproject -t pleiades \
   --tr 0.5             \
   --t_srs "$proj"      \
   ref_dem.tif left.tif left_exact.xml left_map.tif
 mapproject -t pleiades \
   --tr 0.5             \
   --t_srs "$proj"      \
   ref_dem.tif right.tif right_exact.xml right_map.tif

 parallel_stereo --stereo-algorithm asp_mgm                  \
   left_map.tif right_map.tif left_exact.xml right_exact.xml \
   run_map/run ref_dem.tif

point2dem run_map/run-PC.tif

The projection needs to be modified for your area of interest. It is strongly suggested to use an auto-determined UTM or polar stereographic projection (Section 16.57.1).

The value of the --tr option is the ground sample distance. It is normally 0.5 to 0.7 meters for Pleiades PAN images. The XML files should have the GSD value.

8.20.2. Exact and RPC cameras

To compare the linescan (exact) and RPC models, run cam_test (Section 16.9) as:

cam_test --image img.tif --cam1 cam_exact.xml --cam2 cam_rpc.xml \
  --session1 pleiades --session2 rpc

This should give great agreement when it comes to pixels projected from one camera to the ground, then reprojected back to the other one:

cam1 to cam2 pixel diff
Max:    0.00304066

cam2 to cam1 pixel diff
Max:    0.00296764

The camera centers computed by the two methods won’t agree, because the RPC camera model does not store the camera center. ASP then substitutes it with an estimated point on the ray from the camera center to the ground. This disagreement is not an issue in practice.

Commands similar to the above can be used to compare the exact and RPC cameras not to each other but against themselves. This tool will also print timing information for the operation of projecting a pixel to the ground and back.

8.20.3. Pleiades NEO

Several peculiarities make the Pleiades NEO data different from 1A/1B (Section 8.20):

  • The tabulated positions and orientations may start slightly after the first image line and end slightly before the last image line. If these scenarios are encountered, linear extrapolation based on two immediate values is used to fill in the missing values and a warning is printed for each such operation.

  • There is no field for standard deviation of the ground locations of pixels projected from the cameras, so error propagation is not possible unless such a value is specified manually (Section 13).

  • The RPC camera models for a stereo triplet can be rather inconsistent with each other, resulting in large triangulation error. It is suggested to use instead the exact linescan camera model.

8.20.4. Pleiades projected images

Airbus offers Pleiades ortho images, that are projected onto a surface of constant height above a datum. A pair of such images can be used for stereo and terrain creation.

Each ortho image comes with two XML files. The first, with the DIM prefix, stores the projection height, in the Bounding_Polygon XML field, in the H subfield. This height is in meters, above the WGS84 ellipsoid. This file lacks the camera model, unlike the earlier products.

The second XML file starts with the RPC prefix and contains the RPC camera model.

Given two such images forming a stereo pair, the heights should be manually read from the DIM camera files. Then, parallel_stereo should be invoked with the RPC camera files, as discussed in Section 6.1.7.9.

ASP does not support Airbus images that are orthorectified with a 3D terrain model, as that terrain model is not known.

8.20.5. Pleiades tiled images

With some Airbus Pleiades data, each of the left and right images may arrive broken up into .TIF or .JP2 tiles, with names ending in R1C1.tif, R2C1.tif, etc.

These need to be mosaicked before being used. That can be done as follows (individually for the left and right stereo image), using gdalbuildvrt (Section 16.25):

gdalbuildvrt vrt.tif *R*C*.tif

This expects any input .tif file to have an associated .tfw (.TFW) file containing information about how the tiles should be combined.

If both PAN and multispectral tiles are present, use only the PAN ones.

This will create a virtual mosaic, which is just a plain text file having pointers to the subimages. ASP can use that one as if it was a real image. If desired, an actual self-contained image can be produced with:

gdal_translate -co TILED=YES -co BLOCKXSIZE=256 -co BLOCKYSIZE=256 \
  -co BIGTIFF=IF_SAFER vrt.tif image.tif

Note that the size of this image will be comparable to the sum of sizes of the original tiles.

The Orfeo Toolbox provides functionality for stitching such images as well.