dem_mosaic behaviour

[James Hollingsworth]

Hi Oleg,

I've noticed something weird with dem_mosaic... I think it's a bug with --propagate-nodata:

... I have 30 dems, each of exactly the same area, but in each dem there are lots of randomly located holes (nodata=0), with10-30% valid pixels in each case. If I build a median stack using dem_mosaic (ASP build date 21/01/25), thus:
dem_mosaic --threads 4 --median $dem_files -o $home/dem_stack.tif
then the output has mostly nodata values (valid pixels ~2%). So it seems like --propagate-nodata is the default setting, even if I don't select this option.

To check, I re-ran the exact same command using a previous version of dem_mosaic (e.g. StereoPipeline-3.1.1-alpha-2022-10-24-x86_64-Linux), and the output has valid pixels of 70%, which is what I expect. In this case, nodata are ignored when computing the median value for each pixel location.

My suspicion is this is a minor bug in the more recent releases (though I couldn't track down when the change in behaviour started?).

Cheers,

James

[Oleg Alexandrov]

James,

I ran my own testcase with the --median option and the answer was good. The behavior of --propagate-nodata did not change, as I know. 

I wonder if you can share privately a small testcase reproducing the problem. From the code it looks that once dem_mosaic does the proper interpolation in each DEM (which can result in some erosion around no-data grid points), the median calculation should work fine. 

One simple test you can also do is to first do gdalwarp on the input DEMs to make sure they are precisely on the same grid. Then, if those look fine, the dem_mosaic program won't even do its own interpolation, but will simply stack and do the median at each grid point with the data as it is.

Oleg

--
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/e597cc2e-1ba7-436a-80a4-64c8d5e1a96fn%40googlegroups.com.

[Oleg Alexandrov]

The problem here was that the input DEMs had NaN values while the no-data value was not NaN, so they were some kind of invalid hidden pixels. I put a fix.

Before, we had no explicit handling of NaN in dem_mosaic, so not sure how this dataset was working out well. Some of our logic can handle it, some can't, and while the fix I put in now (in a couple of places) will surely guarantee no problems in dem_mosaic, it can't rule out that at some point something else will not have issues. NaNs are usually an afterthought.

[James Hollingsworth]

Mega awesome Oleg. Amazing, as always. But I would encourage people to take care with nans, as they don't show with gdalinfo -stats