[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:  reopened
  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:23 mlennert]:
 > Replying to [comment:22 mmetz]:
 > > Replying to [comment:20 mlennert]:
 > > > Thanks for all these fixes !
 > > >
 > > > r.texture now runs much faster than before and results seem more
 meaningful.
 > > >
 > > > [...]
 > > >
 > > > using 7.0.5 (left) and current trunk (right) for each of the texture
 indicators. On 7.0.5 this takes over 2 minutes, where in trunk it takes
 less than 30 seconds.
 > > >
 > > > Several results now seem more relevant (SV, SA, DV, Contrast).
 Others do not change. I don't know whether this is because they were
 already ok or not. Variance seems to be less clear after the change.
 > >
 > > Fixed in r69877-9.
 > >
 > > > And MOC-2 doesn't give any result (0 everywhere) in both versions.
 > >
 > > That bug was introduced 14 years ago with r11641 when r.texture was
 added to GRASS. An f got lost.
 >
 > Wow. Really sounds like noone has actually ever seriously used r.texture
 before...

 Maybe because noone knows what this is good for? According to Haralick's
 publications, the texture measurements can be used for image
 classification. Could you update the manual if you can suggest
 applications for these texture measurments? Thanks!

 >
 > Thanks for the quick fixes !
 >
 > I've updated the summary image.
 >
 > And now, I'll really stop working on this for now... ;-)
 >
 The manual... r.texture should also be mentioned in the manuals of other
 modules where the output of r.texture might be useful.

 Also, there is potential for more speed optimizations. r.texture is (was)
 essentially a wrapper for the netpbm code, using the netpbm code not only
 once but for each cell separately. The netpbm code was not designed to be
 used like this, instead the purpose was to calculate texture measurements
 over the whole image, providing a single value for each texture
 measurement.

 It does not help that the netpbm code has bugs and that the initial
 version of r.texture introduced more bugs.

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