#3210: r.texture: bug when non continuous series of values
--------------------------+-------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.2.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.texture
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by mlennert):
Replying to [comment:8 mmetz]:
> Replying to [comment:7 mlennert]:
> > Replying to [comment:6 mmetz]:
> > > Replying to [comment:5 mmetz]:
> > > > Replying to [comment:4 mlennert]:
> > > > > Replying to [comment:3 mlennert]:
> > > > > > Just one question:
> > > > > >
> > > > > >
> > > > > > The manual says:
> > > > > >
> > > > > > r.texture assumes grey levels ranging from 0 to 255 as
input. The input is automatically rescaled to 0 to 255 if the input map
> > > > > > range is outside of this range.
> > > > > >
> > > > > >
> > > > > > But when I rescale the above (second) matrix to 0,255 I get a
different result:
> > > > > >
> > > > > >
> > > > > > {{{
> > > > > > r.in.ascii --o in=- out=test_matrix <<EOF
> > > > > > north: 3
> > > > > > south: 0
> > > > > > east: 3
> > > > > > west: 0
> > > > > > rows: 3
> > > > > > cols: 3
> > > > > > 1 1 1
> > > > > > 3 0 0
> > > > > > 0 0 3
> > > > > > EOF
> > > > > > r.texture -s test_matrix out=text method=idm --o
> > > > > > r.stats -1n text_IDM_90
> > > > > > 0.40000007
> > > > > >
> > > > > > r.rescale test_matrix out=test_matrix_rescaled to=0,255
> > > > > > r.texture -s test_matrix_rescaled out=text_rescaled method=idm
--o
> > > > > > r.stats -1n text_rescaled_IDM_90
> > > > > > 0.16672371
> > > > > > }}}
> > > > > >
> > > > > > I would have thought that the result should be the same ?
> > > >
> > > > No, because the differences become larger, therefore IDM becomes
smaller.
> > >
> > > According to Haralick et al. (1973), the gray tones are quantized
which "guarantees that images which are monotonic transformations of each
other produce the same results". Therefore IDM should indeed stay the
same. That also means that the manually calculated result of 0.4 for the
second test matrix is wrong and the correct result is indeed 0.48333332.
> >
> > Well, to be complete, the sentence says "Image normalization by equal-
probability quantizing guarantees..." And an algorithm to perform such
quantizing is given in the appendix. I don't think this algorithm is
implemented in r.texture.
>
> Right. So it seems 0.4 is the correct result for the second test matrix.
This will be a somewhat larger patch.
You mean if you implement the quantizing within r.texture ? I don't think
this is necessary. Informing the user should be enough, including about
how to do it with the existing tools.
Looking over Haralick et al. (1973), I see that i and j are summed over
Ng, where Ng are the grey tone levels that the map is quantized to. The
set Ng contains all grey levels, and so your patch does seem the right
one.
So I would plead for applying this patch...
>
> Equal-probability quantizing could be done with r.quantile + r.recode.
According to literature and other resources, the number of gray levels
should not be too large, at least 16 but apparently less than 256. Maybe a
note in the manual would be helpful.
Yes. If you have a small example of how to do the quantizing it would be
great to add that to the manual.
If you're still planning on looking at r.texture some more, could you also
look at #2325 ? And I also have some doubt about the memory management in
r.texture. In main.c, one can find this:
{{{
for (j = 0; j < nrows; j++) {
Rast_get_row(infd, dcell_row, j, DCELL_TYPE);
for (i = 0; i < ncols; i++) {
if (Rast_is_d_null_value(&(dcell_row[i])))
data[j][i] = -1;
else if (inscale) {
data[j][i] = (CELL)((dcell_row[i] - min) * inscale);
}
else
data[j][i] = (CELL)dcell_row[i];
}
}
}}}
i.e. IIUC the entire map is read into memory. Seems a bit dangerous in
light of some of the images we are dealing with now, and quite
unnecessary. Shouldn't this be dealt with using the segment library ?
But that's a different and bigger issue. For this specific issue, let's
just apply the small patch before getting 7.2 out, or ?
And then, the next step, one day, will be to implement #2111 
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3210#comment:9>
GRASS GIS <https://grass.osgeo.org>