# Calculating rotation invariant GLCM textures

This post outlines how to use the `glcm` package to calculate image textures that are direction invariant (calculated over “all directions”). This feature is only available in `glcm` versions >= 1.0.

## Getting started

First use install the latest version of `glcm`, and the `raster` package that is also needed for this example:

## Calculating rotationally invariant textures

`glcm` supports calculating GLCMs using multiple shift values. If multiple shifts are supplied, `glcm` will calculate each texture statistic using each of the specified shifts, and return the mean value of the texture for each pixel.
In general, I have not found large differences in calculated image textures when comparing GLCM textures calculated using a single shift versus calculating rotationally invariant textures. However this may not be the case for images with strongly directional textures.

To compare for a sample cropped out of a Landsat scene, use the L5TSR_1986 sample image included in the `glcm` package. This is a section of a 1986 Landsat 5 image preprocessed to surface reflectance. The image is from the Volcán Barva TEAM site.

When `glcm` is run without specifing a shift, the default shift (1, 1) is used (90 degrees), with a window size of 3 pixels x 3 pixels. Below is an example from running `glcm` with the default parameters:

To calculate rotationally invariant GLCM textures (over “all directions” in the terminology of commonly used remote sensing software), use: ```shift=list(c(0,1), c(1,1), c(1,0), c(1,-1))```. This will calculate the average GLCM texture using shifts of 0 degrees, 45 degrees, 90 degrees, and 135 degrees:

To compare the difference between these textures, subtract the textures calculated with a 90 degree shift from those calculated using multiple shifts, and plot the result:

## Computation time

First look at the time difference for calculating a GLCM with only one shift versus calculating a rotationally invariant form:

As seen in the above, there is a performance penalty for using a rotationally invariant GLCM (not surprisingly, as more calculations are involved).

Prior to having the ability to use multiple shifts hardcoded in `glcm`, it was still possible to calculate rotationally invariant textures using the `glcm` function. However, the calculation had to be done manually, using an approach similar to what I do below with `glcm_all_dir_manual`. How much faster is it perform the averaging directly in `glcm`?

The time difference isn’t that great, but the need for repeated calls to `glcm` (and the need for multiple read/writes to disk for large files) could lead to a more substantial advantage for the direct approach with `glcm` than is apparent in this simple example. Of course, the manual approach does give more flexibility if you need to do other processing (or scaling, etc.) to the textures.