[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 mmetz):

 Replying to [comment:9 mlennert]:
 > Replying to [comment:8 mmetz]:
 > >
 > > [...] 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 ?

 No, some other measurements need the same patch like IDM.

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

 {{{
 g.region -p rast=ortho_2001_t792_1m
 r.quantile in=ortho_2001_t792_1m quantiles=16 -r | r.recode
 in=ortho_2001_t792_1m out=ortho_2001_t792_1m_q16 rules=-
 }}}

 The frequencies of occurrence are not equal but similar.

 >
 > If you're still planning on looking at r.texture some more, could you
 also look at #2325 ?

 OK.

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

 IMHO, the segment library would be overkill here. Instead, a cache like
 used by r.proj or a mechanism like used by r.neighbors  would be
 appropriate.
 >
 > 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 ?

 I would rather fix all measurements that are affected by collapsing the
 array, taking out zero values.
 >
 >
 >
 > And then, the next step, one day, will be to implement #2111 ;-)

 Technically possible...

 Related, an option to use a circular neighborhood would be nice.

 Before that, NULL values need to be handled. Currently, NULL cells are
 allowed.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3210#comment:10>
GRASS GIS <https://grass.osgeo.org>