#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev