I'm not sure that I understand what you mean. My understanding of spatially invariant features is that they don't move from one image to the next in a sequence of images. But ENVI's texture filter is applied only to one image at a time. So, there is no time sequence over which to determine whether something is spatially invariant. Can you give more details about what it is you are wanting to do? Peg

Hi Peg, Thanks for your response. What I'm trying to do is generate texture features to use in regressions with forest parameter field measurements. According to the literature I've read, since the canopy exhibits no directionally dependent texture pattern, computing the texture features as 'spatially invariant' (where each of the four directions is considered, and the co-occurrence combinations are counted and summed, then statistics are generated from those sums) instead of choosing a specific orientation is recommended. So that's what I'm trying to do -- any ideas? Thanks for your help!

Hmm. Well, any values that you enter for the co-occurrence shift is going to define a shift in a particular direction. There is not any way (in ENVI at least) to calculate a co-occurrence matrix that includes shifts in all directions. So, I guess the answer must be that ENVI cannot calculate a spatially invariant co-occurence matrix. Peg

That's what I figured. I guess the way to do that would be to do features for each orientation, then average them. Thanks for your input, Peg...I'll post here if I figure out a good workflow for this.

Hi Peg, one more quick question: I can use map algebra in Arcmap to average my directional texture features to create spatially invariant features. The one issue I am running into is with the 135-degree orientation image -- it always comes out shifted one pixel to the right in relation to the other orientation images. I've tried using both x = 1, y = -1 and x = -1, y =1 offsets, but both generate the same results. Any idea how to deal with this? Thanks!

Sorry it took me a while to get back to this. I'm not sure why you'd be getting a one-pixel shift when calculating the texture measures with 1,-1 and -1,1 for the co-occurence shift, versus all of your other shifts. But I just tried it myself, and I see that you are right. I don't think this could be correct, so it seems like there must be a bug. Can you remind me which other shifts you've calculated? Maybe that will give us a clue about what it triggering this problem. - Peg