Plans for nodata handling?

OTB Development
1

What are the plans for nodata handling in OTB?
I find the situation confusing:


“Handling no datas in the transformation part requires more work than as initially expected, because some changes need to be done to filter at the core of the library. It will not be a part of merge request !585 (merged). Related issue #1960 (closed)”
But https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/1960 is closed, so there are no plans for nodata support? That would be bad…

2

The conclusion of #1960 was that FunctorImageFilter should remain generic and not handle no-data, this should be done in each Functor. There is no issue on this (yet). Feel free to propose one, as a feature request.
There are other places where no-data could be handled, but at the moment there is no clear roadmap to address this story.

The basic behavior “don’t process no-data pixel” is the first step, but then you get into various corner cases:

  • my algorithm uses neighborhood :
    • local stats
    • Connected components
    • Interpolation
    • …
  • what value should I put in output pixels with no-data ? 0 ? same no-data as input ?
  • what if the output pixel type is different ?
  • what if I need a special behavior on my no-data pixels ?
  • there are also cases where you can’t handle no-data as a specific value, and you have to use a dedicated mask (when you need the whole dynamic of the pixel values)

This is why at the moment, I don’t see a unique feature that will bring no-data support to the whole library, rather specific features to address the different use cases.

3

The general solution would be keeping “any operation with nodata results on nodata” by default, but
adding an option such as na.rm=TRUE in R (I think I recall the equivalent exists in matlab too), which means “ignore nodatavalues”. In that case, if you apply a filter with a window that partially includes nodata values (or you calculate a mean across bands in a multitemporal image), setting na.rm=TRUE would calculate the result with valid values only. But using the actual value of nodata as if it were a valid value is going to be always an error.
I copy this to #1960