[GRASS-user] integration of sample.c algorithms into r.resample

Glynn Clements glynn at gclements.plus.com
Sat Aug 12 19:11:00 EDT 2006


Maciej Sieczka wrote:

> > I've attached a modified version of r.bilinear which does
> > nearest-neighbour, bilinear and bicubic interpolation. It's only been
> > lightly tested, but the case where the source and destination regions
> > match (exact copy) has been tested. It could use some testing at more
> > extreme scale factors.
> 
> > It would be possible to speed it up a bit, at the expense of
> > simplicity, by caching the horizontal interpolates for each row. 
> > However, even in its present form, it's still likely to be a lot
> > faster than using the functions in sample.c.
> 
> I have tested and compared your r.bilinear to gdalwarp output. I took
> care to run gdalwarp and r.bilinear with identical settings.
> 
> In case of naearest neigbor the output is identical.
> 
> In case of biliner and bicubic there is a minor difference between the 2
> programs output, min=-0.000002 and max=0.000002. Exactly the same in
> case of both methods. But this is propably due to the bug that r.in.gdal
> forces FCELL on output http://intevation.de/rt/webrt?serial_num=4897
> while your r.bilinear outputs DCELL. So I guess it is not important.

For IEEE single precision, FLT_EPSILON is ~1.2e-7, so a value of
around 16-17 would have an absolute error of ~2e-6 just due to
rounding error. "r.info slope" indicates that the range of the data is
between zero and 52.5, so that error seems reasonable.

> (A bit OT: what are the Grass equivalents for Gdal's
> Int16,UInt16,UInt32,Int32,Float32,Float64,CInt16,CInt32,CFloat32,CFloat64?
>  I'd like to put such note into r.out.gdal manual, it always puzzles me).

I'm not sure there are equivalents.

Internally, GRASS has three types: CELL (C "int", typically 32-bit
signed integer), FCELL (C "float", typically 32-bit IEEE
single-precision floating-point) and DCELL (C "double", typically
64-bit IEEE double-precision floating-point).

> I was wondering what name should be given to the module. IMO it should
> replace r.resample and r.bilinear should be removed. Is it acceptable
> for Grass 6.3?

I would suggest keeping r.resample. Its output is the result of GRASS'
built-in resampling, and is exactly what any raster module would
obtain from reading the map with the current region settings. The
output from method=nearest in the module which I sent may differ due
to rounding error.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-user mailing list