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

 Replying to [comment:27 mmetz]:
 > Replying to [comment:26 mlennert]:
 > > Replying to [comment:25 mmetz]:
 > > > [...] Could you update the manual if you can suggest applications
 for these texture measurments? Thanks!
 > >
 > > I just committed what I consider some improvements, including a very
 simple, but thus hopefully pedagogical, example. I allowed myself to
 rearrange some of the existing text, including some of your recent
 additions.
 >
 > Thanks for your update on the manual! I am trying to make r.texture
 produce correct results in a reasonable time, but you are actually using
 it, so you know best what should go into the manual. IMHO, the description
 of a manual should be as short as possible (what does the module do, what
 is its output good for). Technical details should go into Notes. In order
 to keep the description short, I suggest to move the second last paragraph
 of the description to notes.

 Ok, I've moved things around quite a lot and added some more notes. Now
 the description is short and focuses on the explanation of the actual
 parameters of the module and more detailed content discussion is in the
 notes.

 > >
 > > Please have a look and if you think this is ok, we can backport to the
 other branches.
 >
 > You decide.

 IMHO, this is ready to go into the other branches, especially 7.2 before
 its release. However, should I merge all of the different commits we did
 in the last days, or can I just copy over the r.texture.html file ? Don't
 know what consequences that has on svn history...


 > About the current defaults of r.texture:
 >
 > The default size of the moving window is 3, and I suspect that the
 reason for this small size is processing time, After what I read, common
 sizes are in the range of 20 - 50 (Haralick et al. (1973): 64), the reason
 is probably calculating texture measurements for a few sample regions. In
 a moving window approach as in r.texture, a smaller window size seems
 reasonable, but a size of 3 might be too small to capture texture in the
 current area.

 This really depends both on the phenomenon you wish to detect and,
 obviously, the resolution of your imagery. 3x3 in Landsat is not the same
 as 3x3 in Pleiades...
 And detecting sill lines in a field with a 1m resolution image should be
 possible with quite small windows, but for detecting tree plantations with
 the same imagery, the windows would have to be much larger...

 I think it is best to leave the default at 3x3, because I wouldn't be able
 to determine another "best" default, and in that case it's probably better
 to leave the default at the lowest processing time.

 >
 > We could remove cropping at margins, the results would not be perfect,
 but better than nothing.

 That's debatable. In my colleagues tests we saw that PCI Geomatica
 "solves" this problem by just replicating the margin row/col as many times
 as necessary depending on window size. This leads to weird textures at the
 margins.

 Another (IMHO preferrable) option would be to calculate the texture with
 just the available pixels, but this would mean that for a 3x3 window you
 would only have one neighbor in each direction (except for the n-s or
 e-w). Don't know if this is an issue ?

 Moritz

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