Low valid pixel percentage when running ASP OpticalBar example

[Nadia Jabeen]

Hi,

I have implemented all steps described in ASP documentation on the same examples given in documentation.

 I have taken 22 GCPS for each backward and forward images. convergence angle is 21 degree.

However, the percentage of valid pixels in the final DEM is very low (around 8%). Because of this, the resulting DEM contains very sparse elevation values.

Could you please advise if such a low percentage of valid pixels is expected when processing this example dataset, or if there might be an issue with my processing steps?

Thank you for your help.

[Oleg Alexandrov]

It is advised to mapproject the images with the cameras used in your stereo processing onto the prior DEM. These should agree reasonably well with the DEM and each other when overlaid in stereo_gui with georeference information. If not, likely the camera models were not solved correctly.

One can overlay on top your problematic DEM as well. Even though it has very few valid pixels, one may get an idea of whether those pixels make any sense as is, or is total mess.

The percentage of valid pixels depends on the application. If to you the DEM looks good when inspected, so in one piece, with not too many holes, covering the expected area, then it may be good.

You can also look at the L.tif and R.tif inside the run directory and see how well they agree when shown on top of each other. There is also the match file there to inspect with stereo_gui as well (its doc has details).

One can look at the search range printed early on on the screen (or saved to log files) for stereo_pprc and stereo_corr. If it is large (say over 100 or 200 pixels) it means the images were likely not correctly aligned, and likely because of the cameras.

The problem with this dataset is that we need to guess and optimize the cameras, rather than them coming from the vendor. So this can be quite tricky, especially with areas without much detail, such as with snow, lack of features, or clouds.

Also look at the DEM triangulation error (the point2dem page talks about it). Large such error means the cameras are problematic.

Hope something helps. You are welcome to share offline any pictures showing the failure.

PS As I recall, you are using the latest recipe in section 8.28, which has the velocity as a parameter with 3 values in the input camera files. These values are later optimized in bundle adjustment. That is the right section. 

--
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 visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/60602842-e5cf-4ae0-a1a3-79006104e89fn%40googlegroups.com.