[gdal-dev] Interpolation questions

Even Rouault even.rouault at spatialys.com
Wed Mar 29 05:39:21 PDT 2017


On mercredi 29 mars 2017 10:07:07 CEST Daniele Romagnoli wrote:
> Hi,
> While investigating on some rendering issues we have with java JAI based
> operations involving interpolations, I have found the topic of bicubic
> interpolation introducing values outside of the input dynamic, as well as
> negative values and overshooting.
> 
> The problem we had was with a grayscale GeoTIFF with noData=0.
> For some very dark area (pixel near to zero) the output of the
> interpolation was a negative value being clamped to zero (which is noData).
> So it was introducing noData in regions where all pixels were valid.
> 
> Therefore I did a test with gdal_translate -r cubic and I got same result:

Hum that the cubic implementation in gdal_translate/gdaladdo (this is the same) has indeed 
not the code that avoids using the noData value for interpolated values. gdalwarp 
implementation normally has code to avoid reusing the noData value, and in this case, it 
would use 1 instead of 0.

> 
> 
>> on the left side: original image
> on the right side: cubic interpolation
> weird white shapes you see on the top right are zero/nodata pixels.
> 
> I got different result once using cubic spline instead.
> What is the difference between the two algorithms?

Different maths...
https://github.com/OSGeo/gdal/blob/trunk/gdal/alg/gdalwarpkernel.cpp#L3063
vs
https://github.com/OSGeo/gdal/blob/trunk/gdal/alg/gdalwarpkernel.cpp#L3126

> 
> Second question:
> I did a gdal_translate -outsize 800% 800% from a small pixellated image.
> is it expected to have output pixels exceeding the original shape of the
> valid input pixels?
> I was thinking the interpolated image pixels should stay within the
> original pixel edges.
> 
> Let me provide an image to clarify:
> 
>>> Left image: original
> Right image: cubic spline.
> See how the 2 edges are different, having the cubic spline producing some
> kind of buffering on the edge (note the white-missing pixels on the borders
> are nodata).
> 
> Please, let me know.
> Best Regards,
> Daniele


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170329/f3ef5e4c/attachment.html>


More information about the gdal-dev mailing list