Horizontal offset in output DEM

[Elise Brehm]

I am processing DG stereo images and have run into an odd discrepancy in outputs that I can’t figure out.

I have images from three dates that I have processed in identical manners, they were all map projected to the same reference DEM and the same processing options were chosen for parallel_stereo and point2dem for all three dates.

However, the final DEM of one of the dates has a fairly significant horizontal offset from its source image and the others do not.

The only difference in the processing of the dates was that the image with the offset was not mosaicked, as there was only one .tif file per side in the DG download.

Output image with the horizontal offset

 

Output image without horizontal offset

 

Has anyone run into this before or have any idea what might cause this? 

[Elise Brehm]

Trying to upload the screenshots again 

No horizontal offset

Horizontal offset

[Oleg Alexandrov]

This may be related to a bug we fixed recently. If your offset is on the order of 15-30 pixels or so, it is likely that. 

ASP has had a discrepancy between WorldView exact and RPC cameras (that can eventually be traced to the vendor, who makes these inconsistent). The exact camera lacks velocity and atmospheric corrections, but RPC apparently has them. Our mosaicking tool creates a new RPC from their exact model, so the created RPC differs from their own RPC. So, using or not the mosaicking tool can result in inconsistent results. 

I put a fix last week or so. The latest build has this, at https://github.com/NeoGeographyToolkit/StereoPipeline/releases. 

Unfortunately this would require redoing all the work from scratch, and likely you want to avoid that.

What you can do with your build is consistently apply mosaicking in all cases, even when there is only a single input file. You will then create DEMs that are actually shifted from where they should be, but all will be shifted in a consistent manner.

If this is the source of the problem, upgrading to the latest may still be suggested, as the new build produces DEMs from WorldView that are better geolocated so one may not need pc_align to later align them. 

[David Shean]

Hi Elise,

Can you confirm the ASP version/build you used to process all 3 pairs? Was it identical?

What is the magnitude of the observed offset in meters?

Are all pairs from same sensor (e.g., wv-3) or are different acquisitions collected by different sensors?

The WV camera models typically have 3-5 m CE90 horizontal geo location accuracy, but some can have horizontal error of 10 m or more, esp images with larger off-nadir angles (35-40+ deg). You can check the XML for mean off nadir angle of each image, and check the expected accuracy in meters, BIAS and RAND tags in RPC group, if I recall correctly. 

Hope that helps

-David

--
David Shean
Civil and Environmental Engineering
University of Washington

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/39196d0f-b977-4a24-894f-0630bf05f979n%40googlegroups.com.

[Elise Brehm]

Thanks for the quick and helpful responses!

They were all processed with a build from early January and the issue was resolved by running dg_mosiac on the date with a single left/right input files. 

I'll be upgrading my build before our next round of image processing. 

Thanks again!

Elise