search

NeoGeographyToolkit / StereoPipeline

The NASA Ames Stereo Pipeline is a suite of automated geodesy & stereogrammetry tools designed for processing planetary imagery captured from orbiting and landed robotic explorers on other planets.
Apache License 2.0
492 stars 173 forks source link

Set nodata values for disparity maps #277

Closed dshean closed 2 years ago

dshean commented 5 years ago

I just hit this again. I believe current disparity maps use a minimum value for nodata in each band. Ideally, we would use a known nodata value. But this change could lead to compatibility issues. Can we at least set known nodata values for each band in the disparity map geotiff header? Want to do this for D_sub, D, RD, F.

oleg-alexandrov commented 5 years ago

The convention is that the third band of D.tif, etc. is a mask. When its value is 1, it is a valid disparity pixel. When it is 0 it is invalid.

For invalid disparities in addition to setting the mask to 0, I think the x and y values are also set to 0. But this is not foolproof, because a valid disparity can also be (0, 0), but with a 1 value in the mask.

I guess we could define a no-data-value, say the smallest negative integer, and not only set the mask to 0 but also set the pixel value to this no-data value. This will be compatible with what is there now. It would require small changes in many places.

Alternatively, we could implement this just in disparitydebug. It can be allowed to split the x and y bands without scaling them to int, so keeping the original disparities, but peeking at the mask and setting the invalid disparities from 0 to the no-data value.

Is it burdensome to take into account the third band in your analysis?

dshean commented 5 years ago

Yeah, my workaround was to read 3rd band and use as mask. There is a performance hit with this, especially for large disparity maps from DG imagery. But it works for now.

Your proposed solution using smallest negative integer as nodata for bands 1 and 2 seems like the best option, though I realize this might require some work, and only a small group of users will ever benefit. So lower priority, but good to have on the list.

If we were starting from scratch, I imagine that the 3rd band mask (as well as L_mask, L_sub_mask, etc) would be unnecessary, as we could use more standard nodata handling throughout ASP/VW.