Hi,
I haven't done myself that exercice but I know that computing RPC values
that are stable enough might be challenging, so perhaps the issue is
related to that
A few other remarks:
- your gdalwarp command line refers to RPC_DEM_SRS and
RPC_DEM_MISSING_VALUE but doesn't include a RPC_DEM itself, hence those
are likely to be non effective
- you generally don't want to use both RPC_HEIGHT and RPC_DEM.
RPC_HEIGHT is essentially useful when you don't have a DEM available,
and thus fallback taking an average elevation
- there's a subtlety regarding DEM. RPC reference for altitudes is WGS84
ellipsoidal height, not orthometric/MSL altitude. But DEM values use
orthometric/MSL altitude, hence a geoid correction must be applied. So
you'd rather want to use RPC_DEM_SRS=EPSG:4326+5773 for example to use
the EGM96 geoid (cf https://github.com/OSGeo/gdal/issues/3298). That
said, misusing orthometric altitude vs ellipsoidal height generally
accounts for small shifts, not big ones
- you could use gdaltransform with all your -to parameter and
input_with_RPCs.tiff to check at least that the forward RPC
transformation path works correctly (the one from longitude, latitude ->
column, line). And with -i to check the inverse RPC transformer. The
inverse RPC transformer can have a hard time converging in montainous
areas or for images off-nadir
Even
Le 17/04/2024 à 23:30, Joseph McGlinchy via gdal-dev a écrit :
Hello,
I am attempting to implement georegistration through RPC. I have the
following information I've used to calibrate the RPC coefficients,
using all terms for numerator and denominator for both sample and line
equations.
*
image grid, stored in tiff format with no geo-information
associated with it, so it reflects the imaging orientation
*
a 'ground' grid, which corresponds to the longitude/latitude
coordinates for each pixel determined from a line-of-sight vector
and imaging system coordinates where the pseudo-rays intersect the
WGS84 geoid
*
a random sample of up to 4000 image coordinate / object space
coordinate pairs (I arrived at this number through trial and
error; using all pixels explodes RAM)
*
elevation extracted at the longitude/latitude coordinates from a
DEM, in this case, SRTM, but have also tried using NASADEM
I am able to write out an image to EPSG:4326 by populating the RPC
metadata and using the non-georeferenced image data. However, I am
struggling to use |gdalwarp| in a reliable way to orthorectify that
data, let alone writing it out in a way that 'bakes in' the
georegistration with the RPCs whether that is in EPSG:4326 or the
local UTM zone. I see strips of the image "ripped out" with odd curves
in various places throughout the image.
The only way I've been able to use |gdalwarp| to write the image at
all is with the following parameters (any DEM reference is to the SRTM
DEM):
gdalwarp --config CPL_DEBUG ON -t_srs EPSG:32610 -rpc -to
"RPC_DEM_SRS=+proj=longlat +datum=WGS84 +no_def" -to "RPC_HEIGHT=350"
-to "RPC_DEM_MISSING_VALUE=0.001" -to "RPC_FOOTPRINT='POLYGON ((list
of polygon coordinates comprising the long/lat grid))'" -to
"RPC_MAX_ITERATIONS=101" input_with_RPCs.tiff output.tiff
This is the only configuration i can use to run |gdalwarp|
successfully. removing any single RPC_X tranformer option gives me
bogus output. The RPC_HEIGHT value i specify above is not close to the
mean or median elevation of the extent of my data; mean is ~195m and
median is ~150m.
With the debug turned on, any other set of parameters gives me failed
RPC convergence on several points. I am able to reproduce this
regularly by specifying RPC_DEM=dem.tif, where dem.tif is the same
data I used to extract elevation values when calibrating the RPCs. I
am seeing normalized latitude and longitude values with magnitude > 1
(I checked every location in the image, based on the metadata, the
range is not outside of [-1,1]), as well as normalized altitude values
with magnitude > 1 (there are some, not many, that have magnitude of
1.75).
My workflow can be summarized as:
1.
load grids (image data, longitude, latitude)
2.
randomly sample up to 4000 points in image coordinates, object
coordinates
1.
assign z-value from SRTM DEM
2.
evaluate if any of the points are in NODATA areas of SRTM
(image is coastal, so there are NODATA areas for SRTM here),
if so, remove those and generate more points
3.
normalize coordinates of grids to be in [-1,1], recording offsets
and scale
4.
calibrate RPC coefficients using all terms
5.
write out GeoTIFF with image grid for pixels, along with RPC
required metadata fields and CRS EPSG:4326
System information (please let me know if more is needed)
OS: Ubuntu 20.04 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2
x86_64) (Windows Subsystem for Linux)
GDAL 3.6.0 (python)
Thank you in advance for any insight into this process! I am happy to
package up any of the data I am using, as well. I have placed the
initial data from the end of Step 5 described above, along with some
additional files, a sample gdalwarp call, and a file-list.txt, at
https://drive.google.com/drive/folders/1BfevhKQa4ZHi_OQfiX_rUk2sqeoNVhyM?usp=sharing
<https://drive.google.com/drive/folders/1BfevhKQa4ZHi_OQfiX_rUk2sqeoNVhyM?usp=sharing>
If more is needed for anyone interested in having a look, please let
me know and I'll upload.
Cheers,
Joe
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
