[GRASS-dev] [GRASS GIS] #3293: r.texture: very slow when size is increased

[GRASS GIS]

#3293: r.texture: very slow when size is increased
--------------------------+-----------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.4.0
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  r.texture speed
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-----------------------------

Comment (by mlennert):

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:3293 mlennert]:
 > > Running
 > >
 > >
 > > {{{
 > > r.texture -a ortho_2001_t792_1m size=27 out=text_ortho_27
 > > }}}
 > >
 > > in the NC demo data set took the following time:
 > >
 > >
 > > {{{
 > > real        339m54.922s
 > > user        339m44.824s
 > > sys 0m5.464s
 > > }}}
 > >
 > > This seems excessively long, especially when the relevant literature
 cites common sizes of 20-50 (see #3210 for a discussion).
 >
 > Note that e.g. Haralick et al. (1973) did not use a moving window
 approach, instead texture measurements were calculated for selected blocks
 and the output is not a raster map but a single value for each texture
 measurement and each block.

 Yes. But I find the pixel-by-pixel version quite nice ! ;-) This said, a
 per-object texture measurement would also be nice... See #2111.

 > >
 > > It would be great if this could somehow be accelerated.
 >
 > Maybe by processing moving windows in parallel, at the cost of
 allocating / freeing memory for each moving window.

 Yes, I've thought about this as well. This seems like a perfect example of
 a module that could profit from parallelisation across as many
 cores/threads the user choses. Memory usage is very low, so this will not
 be a bottleneck (except for large images as the module still reads in the
 entire data, no ?). And allocation only has to happen once at the
 beginning, and then you can just use the allocated window throughout, or ?

 Might be interesting to benchmark where exactly most time is lost. Any
 hints on how to do that ?

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