[gdal-dev] Prevent extrapolating with ReadAsArray when resampling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Prevent extrapolating with ReadAsArray when resampling

Rutger
Dear list,

I regularly use (and enjoy!) the resampling option when using the
ReadAsArray method of a Dataset. However, i noticed that in the case of
nodata values in the raster, the method extrapolates "into" those nodata
values. This is not always desirable in my case, especially when using any
resampling algorithms other than Bilinear or Nearest, since these can
overshoot significantly.

This made me wondering if there is a way to prevent this extrapolation? One
thing i noticed it that when the nodata value is non-numerical, like NaN,
there is a lot less extrapolation (eg more nodata values returned). That
could be used a workaround, but it not convenient to map numerical nodata to
NaN values before reading the input.

In the process of exploring the behavior, i also encountered some issues
(perhaps a bug?) when using Lanczos in combination with certain datasets and
certain output grids. This happened especially when the output size is an
uneven factor of the input size, like (buf_xsize=xsize*3, buf_ysize=ysize*3)
or (buf_xsize=xs*5, buf_ysize=ys*5) etc.

Here is a notebook showing what i did with a linearly increasing grid:
https://gist.github.com/RutgerK/30fbd03d9b2ab79861eedfbb95064732

And a random grid:
https://gist.github.com/RutgerK/bdbd6c124224cf49961082e1620ce604

Regards,
Rutger





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Prevent extrapolating with ReadAsArray when resampling

Even Rouault-2

Rutger,

 

ReadAsArray() / IRasterIO() with non-nearest resampling use the interpolation code of overview building (except for Lanczos where it uses the warping code), which was of course targetted at downsampling rather than upsampling. Nodata is taken into account when mixing together source pixels for a target pixel (those pixels are assigned a zero weight in convolution computations), but it seems that we should likely skip entirely a target pixel if the center source pixel corresponding to it is nodata, so that nodata areas do not fade away (which is done in the warping code). What surprises me is that you get different results depending on the nodata value (I could also see that)

 

Regarding Lanczos, might be a bug specific to it indeed. Didn't look.

 

Perhaps file this as a ticket about this.

 

Even

 

> Dear list,

>

> I regularly use (and enjoy!) the resampling option when using the

> ReadAsArray method of a Dataset. However, i noticed that in the case of

> nodata values in the raster, the method extrapolates "into" those nodata

> values. This is not always desirable in my case, especially when using any

> resampling algorithms other than Bilinear or Nearest, since these can

> overshoot significantly.

>

> This made me wondering if there is a way to prevent this extrapolation? One

> thing i noticed it that when the nodata value is non-numerical, like NaN,

> there is a lot less extrapolation (eg more nodata values returned). That

> could be used a workaround, but it not convenient to map numerical nodata to

> NaN values before reading the input.

>

> In the process of exploring the behavior, i also encountered some issues

> (perhaps a bug?) when using Lanczos in combination with certain datasets and

> certain output grids. This happened especially when the output size is an

> uneven factor of the input size, like (buf_xsize=xsize*3,

> buf_ysize=ysize*3) or (buf_xsize=xs*5, buf_ysize=ys*5) etc.

>

> Here is a notebook showing what i did with a linearly increasing grid:

> https://gist.github.com/RutgerK/30fbd03d9b2ab79861eedfbb95064732

>

> And a random grid:

> https://gist.github.com/RutgerK/bdbd6c124224cf49961082e1620ce604

>

> Regards,

> Rutger

>

>

>

>

>

> --

> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html

> _______________________________________________

> gdal-dev mailing list

> [hidden email]

> https://lists.osgeo.org/mailman/listinfo/gdal-dev

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev