PeruSat-1 exact linescan camera model support?

[rsignell-usgs]

In section 10.14 of the documentation it says

DigitalGlobe/Maxar provides both exact linescan camera models and their RPC approximations and ASP supports both. Apparently such is the case as well for PeruSat-1, but ASP supports only the RPC model for this satellite.

What would it take to support exact linescan camera models for PeruSat-1?

Would there be a way to fund someone to develop it?

We are working with Peru and the orthos are off by 10m, we suspect it's due to the RPC model used. That might not be too bad in some cases, but this is 1m resolution panchromatic, 2m multispectral imagery!

This is a sample "di*xml" file.

Does it contain what would be needed?

[oleg-alexandrov]

Thank you for pointing out that there exists a linescan model for PeruSat.

I took a look at the XML file, and the format seems to be reasonable enough, a list of quaternions at certain times, presumably with camera poses along the flight path. It looks like it has what we need, and it should be rather straightforward to map that to our linescan model implementation, I guess, likely requiring maybe a couple of weeks of work including testing and taking into account planning for some unexpected things.

I see you are with USGS. I am currently tasked to do two other projects with USGS in ASP, and we've done more in the past. In principle, if it is possible for you to get funding it should work. It takes a good amount of planning ahead though. As I know, at some point late in the Summer we'll finalize the funding and planning for fiscal year 2022, and then the next window of opportunity will come only in FY23.

Note that our software is open-source, we accept external contributions, and this kind of work is also rather straightforward. Mabe a third-party can be hired to do it, likely at a cheaper rate than what we'd charge, and I could help with advice as needed.

[rsignell-usgs]

@oleg-alexandrov , thanks so much for your speedy reply!
Indeed we have some funds that might cover this work.
Would you be willing to send me an email at rsignell@usgs.gov to continue the funding discussion offline?

[oleg-alexandrov]

I made ASP work with the exact PeruSat-1 linescan model. I did quite a bit of extensive testing, when it comes to camera direction, intersection error, and DEM generation. I followed carefully all the supplied docs for this exact sensor and the RPC one, and also compared with the doc for the similar SPOT-6 camera.

The intersection error maps obtained with the exact and RPC models are very similar, with their mean differing by less than 3 cm, and showing a very similar pattern. There is about a 15 meter systematic vertical shift between the DEMs created with the exact vs RPC models which I could not figure out where it comes from. There is nothing in the metadata or the docs about it. But pc_align takes care of it, and the absolute difference of the two DEMs gets reduced to under 17 cm after alignment is applied. No obvious pattern is seen when these DEMs are differenced after alignment.

I experimented with not using linear interpolation between poses as we do for Digital Globe but using instead smoother Catmull-Rom splines, as the doc suggests cubic interpolation. The DEM changes by a mean of 2 cm and there is no wavy pattern in their difference, which means that the interpolation type does not matter much. Hence the bilinear interpolation is still used.

Overall, I can't say the exact model is an improvement, but adding it was instructive. Note that the SPOT6 model is very similar to PeruSat, a lot more so than to SPOT5 which we already support, so adding support for SPOT6 will be easy should we ever need it.

The PeruSat-1 implementation won't use atmospheric correction and velocity aberration correction (unlike the exact DigitalGlobe model) as I noticed that this would make the result differ a little more from the one obtained with the RPC model. This is a small correction anyway, but it would be nice to study this in more depth at some point.

Stereo with mapprojected PeruSat-1 images using the exact model is not implemented. This model is too slow for such a thing (just as the exact Digital Globe model is too slow). One could mapproject with RPC cameras provided with PeruSat, then do stereo with exact cameras, but that would be awkward as ASP would need to have access to both exact and RPC models which for PeruSat (unlike Digital Globe) are stored in different files.

In short, the exact PeruSat-1 model is ready to be used, and it does well. The minor things noted above won't affect its use. The nightly build at https://github.com/NeoGeographyToolkit/StereoPipeline/releases has the implementation, and the doc is at https://stereopipeline.readthedocs.io/en/latest/examples.html#perusat-1.

[oleg-alexandrov]

I found a blurb in the PeruSat documentation (Modelamiento Geométrico Orbital para imágenes PeruSAT-1), which, when translated from Spanish, says:

The results show that using RPCs an RMS of 15.21 and 12.91 m for longitude and latitude is obtained, respectively. However when using the orbital model with position ephemeris data (X, Y Z) and a SRTM 30 Digital Elevation Model, an RMSE of 6.12 and 8.21 m is obtained for longitude and latitude.

Not quite the same thing as the vertical 15 m shift I see above, but the numbers are about right, and it does show that the PeruSat folks are also aware the RPC and exact models have differences.

[rsignell-usgs]

Overall, I can't say the exact model is an improvement, but adding it was instructive.

@oleg-alexandrov, so the exact model didn't have much impact on the DEM structure, but it did help the horizontal RMSE for lon/lat, right?

[oleg-alexandrov]

At least that's what they claim, and the vertical shift that I noticed between the DEMs with exact and RPC model seem to be consistent with that.

I find this rather confusing. This 15 m shift can be easily absorbed in the RPC model by adjusting that model's height offset value (HEIGHT_OFF).

Also, given that this satellite has a ground resolution of 0.9 meters, it is also surprising all their error measurements are so large, on the order of 6-15 meters. Those could be coming from the fact that they measure against SRTM, which is a 30 meter resolution DEM.

The fact that after aligning the DEMs obtained with the exact linescan model and with the RPC model the height error decreases to 17 cm, which is a fraction of the 90 cm GSD, shows that the RPC approximation in fact has the capacity to approximate the exact model quite well, and there is a little mystery in how their RPC fit resulted in simply a very large systematic shift rather than some variable nonlinear discrepancy spread all over the footprint of the DEM.

[dshean]

Is it possible that this is related to geoid offset handling somewhere along the line? Pretty variable over Peru (second attachment), but ~15 m in places. Seems unlikely that they would use height above ellipsoid for one model and height above geoid for another, but easy to make mistakes with earlier SRTM products.

On Sep 30, 2021, at 8:40 AM, Oleg Alexandrov @.***> wrote:

At least that's what they claim, and the vertical shift that I noticed between the DEMs with exact and RPC model seem to be consistent with that.

I find this rather confusing. This 15 m shift can be easily absorbed in the RPC model by adjusting that model's height offset value (HEIGHT_OFF).

Also, given that this satellite has a ground resolution of 0.9 meters, it is also surprising all their error measurements are so large, on the order of 6-15 meters. Those could be coming from the fact that they measure against SRTM, which is a 30 meter resolution DEM.

The fact that after aligning the DEMs obtained with the exact linescan model and with the RPC model the height error decreases to 17 cm, which is a fraction of the 90 cm GSD, shows that the RPC approximation in fact has the capacity to approximate the exact model quite well, and there is a little mystery in how their RPC fit resulted in simply a very large systematic shift rather than some variable nonlinear discrepancy spread all over the footprint of the DEM.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NeoGeographyToolkit/StereoPipeline/issues/334#issuecomment-931438287, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAINNKQJ7MIVC5LAOVZS6XTUESAF7ANCNFSM47J4QHIQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[oleg-alexandrov]

Good point, there's a chance PeruSat's disagreement between the exact and RPC model is a geoid/ellipsoid mixup. Likely not an issue in practice, if one knows that the systematic vertical shift amon the two exists and if there exists a reference DEM to which to align any of these products to (eg, Copernicus). This issue is documented at https://stereopipeline.readthedocs.io/en/latest/examples.html#perusat1.