[GRASS-dev] bilinear and bicubic raster interpolation

Markus Metz markus.metz.giswork at googlemail.com
Sun Oct 17 02:01:14 EDT 2010


Hamish wrote:
> Markus Metz wrote:
>> In i.rectify, I have implemented the interpolation methods available
>> in r.proj, and while testing discovered an offset of one cell (row +
>> 1, col + 1 from source to target) between the source and target
>> imagery after rectifying (40+ automatically collected GCPs, order=1,
>> sub-pixel RMS errors, source image not distorted). I corrected this
>> offset in i.rectify and suggest that all modules using
>> Rast_interp_linear/Rast_interp_bilinear/Rast_interp_cubic/Rast_interp_bicubic
>> should be checked. I am pretty sure that at least r.proj needs this
>> fix (if a one-cell shift is something to worry about).
>
> For MODIS satellite data the cells can be 4km tall, for GRIB data 1/2 degree
> or full degree. So once reprojected from eg lat/lon to UTM, the cells are
> still quite big and a 1 cell offset can be significant when trying to
> ground-truth against in situ measurements.
>
> also, i.rectify and gdalwarp share the same code source for order= matrix
> calcs, so maybe we should check for the same there if that was touched.
>
The transformation matrix code (crs.[c|h]) wasn't touched. This cell
shift really only applies to linear and cubic interpolation. My point
is that a reprojected or transformed or recalculated (in case of
resampling within the same projection) cell center (result is floating
point) of e.g. row 2.1 is in between row centers 1.5 and 2.5 because
1.5 < 2.1 < 2.5, and not in between row centers 2.5 and 3.5, thus (for
linear ip) rows 1 and 2 should be used and not rows 2 and 3, same for
column indices and cubic ip.

Markus M


More information about the grass-dev mailing list