[GRASS-dev] [GRASS GIS] #3210: r.texture: bug when non continuous series of values

[GRASS GIS]

#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>