I’m trying to ortho a Pleiades bundle against a reference image. However, regardless of my inputs my results are poor - the best accuracy I have obtained is roughly 10 meters.
Big picture my question is how can I perform residual registration with better accuracy?
My use case
To help illustrate my scenario please see orfeo-fine-registration.zip (105.1 KB) for details on a specific use case.
I pan-sharpen the Pleiades bundle with otbcli_BundleToPerfectSensor then proceed with the the residual registration recipe. I’m using default parameters unless noted.
OTB version: 6.6.1
Input imagery: Pleiades bundled imagery, processing level is Sensor
Reference imagery: ~1m RGB 8-bit data
- I prepare the data by reprojecting it from Web Mercator (3785) to WGS84 (4326). I have also tried tests using the appropriate WGS84 UTM zone.
- I have tried up-sampling to have an equivalent resolution with the fused Pleiades data (~.54m).
- I default to resampling with cubic but have also tried bilinear and nearest neighbor.
- The extent of my reference imagery is typically larger than the Pleiades bundle (I’m not clipping just ensuring coverage.)
Input dem: Most of my tests use SRTM and geoid (as provided in the OTB-Data repo.) I have also tried using 10m NED.
General observations
- The number of homologous points produced is generally in the thousands (2-3K.)
- The reported estimated accuracy when refining the sensor model appears large (200m or greater).
Testing notes
I’ve ran through a chunk of trial and error by adjusting the input arguments for HomologousPointsExtraction. I’ve been unable to find any real improvement despite adjusting threshold, backmatching, geobin size, precision,…
Other Questions
I’d like to understand input requirements and constraints.
- How much parody must exist in the resolution of reference and slave imagery?
- What projections are supported/required for reference and dem imagery? WGS84 and appropriate UTM zones seem to produce roughly similar results.
I’d like to understand command parameters, specifically for HomologousPointsExtraction.
- What are the units for arguments such as threshold (is this pixels, meters,…?)
- Is there a rule of thumb or process I can use to refine the values and options to use for a given use case? I assume the defaults may not be the best for this use (and others.)
- Broadly, just more information… having a hard time finding documentation.
Hi,
I will try to answer some of your points:
-
You may not need to resample your reference image. SIFT/SURF algorithm should be able to find matches even with a scale factor of 2, and rotations. Also, the application HomologousPointsExtraction has an option 2wgs84 which will convert the coordinates from reference image to WGS84.
-
For a better accuracy, I would also suggest to specify an input geoid file elev.geoid (like egm96)
-
The threshold is the same as the reference paper on SIFT/SURF: it is normalized between 0 and 1, and corresponds to the ratio between the nearest key point distance over the second nearest key point distance. Basically, a threshold closer to 0 means a more restrictive matching between homologous points. The default value of 0.6 should be adapted in most cases.
-
What you can check:
- Visual localization of some homologous points between reference and slave image: do they roughly corresponds to the same features?
- In general, the validity of the matching can be assessed by plotting the displacement vectors in an artificial configuration where the reference and slave image are next to each other. Then it is easy to spot wrong matches as their vectors are very different from the general “motion”.
- Are the homologous points located mostly on the ground? If not, there can an error in the elevation estimation because the DEM represents the ground, not buildings and vegetation. Depending on the viewing angles on both images, this error may vary.
- Check that your DEM is correctly handled. With Monteverdi, you can setup different DEM and check the reprojected coordinates of some points in the scene. You should see some differences between no-DEM / SRTM / NED.
Hope It Helps
For reference, an ortho using the RPC model results in much better accuracy than residual registration.
The results of HomologousPointsExtraction feels nearly arbitrary. Visually, the displacement vectors have no general motion; bearings and magnitude are all over the place. The homologous points often do not look like they are aligned with a feature. Most of the points are on the ground.
I feel I am doing something fundamentally wrong as I see no consistency.
Here’s a sample of three test cases. They use default parameters with Ned 10M and the egm96.grd geoid. Red is using default parameters, green is after reprojection of the reference imagery to WGS84, and yellow is when testing the WGS84 reference with SURF instead of SIFT.
Hi,
It may be difficult to plot properly the results of HomolgousPointsExtraction. Please note that the points coordinates are expressed as physical coordinate (i.e. if the image is projected, the index (i,j) is translated into ground coordinate (x,y) relative to the ProjRef).
I also forgot to tell you about ortho-ready products. Some sensor products come with an approximate geo-referencing, and OTB may use it by default. You can check it with the application ReadImageInfo. For a proper sensor image, you should get an empty ProjectionReference and a valid KeywordList.
