# glcm R package correlation metric values outside bounds of -1 to +1

I've been using the glcm package in R to calculate various texture measures of raster data sets; however, I've been getting odd values for the correlation measure which should be constrained to -1 to +1. Although most values fall in this range, some pixels are assigned -Inf or Inf, and some pixels are assigned real numbers greater than 1. I've searched but haven't found anything about this issue and was wondering if anyone knew what would cause this and how to account for it. Below is a small reproducible example using R's volcano data set:

``````library(raster)
library(glcm)

rast<- raster(volcano)
textures<- glcm(rast)

hist(textures\$glcm_correlation) #Most values in valid range (-1 to +1)
cellStats(textures\$glcm_correlation, max) #Maximum Value is Inf
# Inf
cellStats(textures\$glcm_correlation, min) #Minimum Value is -Inf
# -Inf

head(sort(unique(textures\$glcm_correlation@data@values), decreasing = TRUE)) #There are real number values >1
#      Inf 5.839971 1.000000 1.000000 1.000000 1.000000
head(sort(unique(textures\$glcm_correlation@data@values), decreasing = FALSE)) #-Inf is <0 but there are no real number values <0
#       -Inf -0.5735393 -0.5000000 -0.5000000 -0.4588315 -0.4335550
``````

How are you defining the grey levels? You should always look at the assumptions of a given model. In the GLCM literature the standard definition for "number of grey levels" is binary = 2 and numeric = 8. These are the respective values that should, as a starting point, be passed to the n_grey argument. In your example, if you use n_grey=8, the max correlation value is 1 but, other data is dropping out as NA or inf. The model does seem to be fairly sensitive to this parameter (try 16) and for some reason the default is 32 (perhaps for floating point). The code in the glcm package seems sound but to truly evaluate it take a look at the glcm_calc_texture C code called from glcm:::calc_texture.

On cursory examination, when applied to a small matrix, the results I am getting with the `glcm::glcm` function track with calculating GLCM's in Matlab using:

``````GLCM = [0 1 2 3;1 1 2 3;1 0 2 0;0 0 0 3];
stats = graycoprops(GLCM)
GLCM2 = graycomatrix(m,'Offset',[2 0;0 2]);
stats = graycoprops(GLCM2,{'contrast','homogeneity','correlation','entropy'})
``````

For returning the moments in R I would recommend using `summary` with `values` to fetch the values in the x@data@values slot.

``````textures<- glcm(rast, min_x=94.0,max_x=195.0, n_grey=8)
summary(values(textures\$glcm_correlation))
``````

The inf and -inf represent a positive/negative infinite value (eg., 10^310) and if applied to another inf value results in a NaN (not a number). This is just how the math of the function is working out. If you are really concerned about this, and bounded expectations, contact the package maintainer, Alex Zvoleff (azvoleff@conservation.org), for an explanation.

If you want to address these infinite values, in the same way that you would NA's, you can use `is.finite`, `is.infinite` and `is.nan` to assign NA or real values.

``````textures\$glcm_correlation[is.infinite(textures\$glcm_correlation)] <- NA
textures\$glcm_correlation
plot(textures\$glcm_correlation)
``````

If values occur out of the +/- expected distribution, just truncate them to the expected range. This is perfectly acceptable statistical practice unless, of course, the math is incorrect.

``````textures\$glcm_correlation[textures\$glcm_correlation > 1] <- 1
``````
• Doesn't seem to work for me, but good to know that truncating the values is acceptable practice. Even after changing the infinites to NA's, summary(values(textures\$glcm_correlation)) still shows a maximum of 5.84. I haven't had any luck contacting the package author, but I might try finding someone who has access to ENVI and use that to calculate the texture measures and see if they are similar. – ailich Apr 10 '18 at 20:28
• @ailich, please see my edits. It would be prudent for you to explore the sensitivity of the n_grey parameter. – Jeffrey Evans Apr 10 '18 at 21:54
• Thank you for the advice. I'll try messing with that input a bit and compare results to other software on small and large rasters. – ailich Apr 11 '18 at 2:26