[GRASS-dev] interp_type: cubic | bicubic

Hi,

recently I have added a standardized option for sampling interpolation
methods [1], based on lib/raster/sample.c and codes defined in
raster.h [2].

Some modules use 'bicubic' other 'cubic' value. What do you think that
is more preferable? It's bicubic interpolation [3] accomplished using
cubic convolution, right?

Martin

[1] http://trac.osgeo.org/grass/changeset/56211
[2] http://trac.osgeo.org/grass/browser/grass/trunk/include/raster.h#L21
[3] http://en.wikipedia.org/wiki/Bicubic_interpolation

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Martin Landa wrote:

recently I have added a standardized option for sampling interpolation
methods [1], based on lib/raster/sample.c and codes defined in
raster.h [2].

Some modules use 'bicubic' other 'cubic' value. What do you think that
is more preferable?

Whichever is used, it should be consistent. I.e. either
nearest/linear/cubic or nearest/bilinear/bicubic.

The former might be preferable if we want to extend it to 3D
interpolation (i.e. use nearest/linear/cubic regardless of the
dimensionality, rather than using separate 2D/3D terminology).

It's bicubic interpolation [3] accomplished using cubic convolution,
right?

Right.

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

Hi,

2013/5/16 Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

recently I have added a standardized option for sampling interpolation
methods [1], based on lib/raster/sample.c and codes defined in
raster.h [2].

Some modules use 'bicubic' other 'cubic' value. What do you think that
is more preferable?

Whichever is used, it should be consistent. I.e. either
nearest/linear/cubic or nearest/bilinear/bicubic.

The former might be preferable if we want to extend it to 3D
interpolation (i.e. use nearest/linear/cubic regardless of the
dimensionality, rather than using separate 2D/3D terminology).

I fully agree, otherwise we will end up using bilinear, trilinear,
bicubic and tricubic.

Best regards
Soeren

It's bicubic interpolation [3] accomplished using cubic convolution,
right?

Right.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Thu, May 16, 2013 at 11:37 AM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:

Hi,

2013/5/16 Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

recently I have added a standardized option for sampling interpolation
methods [1], based on lib/raster/sample.c and codes defined in
raster.h [2].

Some modules use 'bicubic' other 'cubic' value. What do you think that
is more preferable?

Whichever is used, it should be consistent. I.e. either
nearest/linear/cubic or nearest/bilinear/bicubic.

The former might be preferable if we want to extend it to 3D
interpolation (i.e. use nearest/linear/cubic regardless of the
dimensionality, rather than using separate 2D/3D terminology).

I fully agree, otherwise we will end up using bilinear, trilinear,
bicubic and tricubic.

+1

Markus M

Hi,

2013/5/16 Glynn Clements <glynn@gclements.plus.com>:

Whichever is used, it should be consistent. I.e. either
nearest/linear/cubic or nearest/bilinear/bicubic.

The former might be preferable if we want to extend it to 3D
interpolation (i.e. use nearest/linear/cubic regardless of the
dimensionality, rather than using separate 2D/3D terminology).

OK, done in r56327, any review welcome of course. Probably would make
sense to incorporate into raster lib as INTERP_TYPE (see
lib/raster/sample.c) other methods, at least `lanczos`.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hi,

2013/5/21 Markus Neteler <neteler@osgeo.org>:

It would be important to also update the HTML pages:

cd grass70/dist.x86_64-unknown-linux-gnu/docs/html
grep 'bilinear\|bicubic' * | wc -l
53

otherwise it becomes inconsistent...

I am not sure if we can replace all occurrences in the manual
automatically (eg. by `sed`). Probably it will need some extra care(?)

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Martin wrote:

I am not sure if we can replace all occurrences in the
manual automatically (eg. by `sed`). Probably it will need some
extra care(?)

perhaps some combination of 'grep -rI' for hits, a quick look at
the file it found, then 'sed -i -e' on the file if it's ok? could
be pretty quick for something as rare as bilinear. When describing
the method it is perhaps good to leave some mention of "bilinear"
and "bicubic" in the help pages, to aid with web/module description
searches where "linear" and "cubic" would be too generic terms to
get to the right answer quickly.

see also the grass-addons/tools/svngrep script to help avoid
some false positives in doing the recursive greps.

Hamish

ps- Martin, any comment on #1971? thanks

On Tue, May 21, 2013 at 10:54 AM, Martin Landa <landa.martin@gmail.com> wrote:

2013/5/21 Markus Neteler <neteler@osgeo.org>:

It would be important to also update the HTML pages:

cd dist.x86_64-unknown-linux-gnu/docs/html
grep 'bilinear\|bicubic' * | wc -l
53

otherwise it becomes inconsistent...

I am not sure if we can replace all occurrences in the manual
automatically (eg. by `sed`). Probably it will need some extra care(?)

I have done most (all?) manually:
http://trac.osgeo.org/grass/changeset/57279
    bilinear -> linear; bicubic -> cubic

cd dist.x86_64-unknown-linux-gnu/docs/html
grep 'bilinear\|bicubic' * | wc -l
43

Still to be done:
i.ortho.rectify.html
i.rectify.html
rasterintro.html
r.fillnulls.html
r.resamp.bspline.html
r.resamp.interp.html
topic_surface.html
v.drape.html
vector.html
v.lidar.correction.html
v.lidar.edgedetection.html
v.outlier.html
v.sample.html
v.surf.bspline.html

Markus