How does CP reduce Gabor wavelets to a single output?



In MeasureTexture, when specifying multiple angles to compute for Gabor features, ExportToSpreadsheet nonetheless gives a single output. How is that output calculated (max? mean?), and is it possible to get the value at each angle?



From the module help:

MeasureTexture performs a vectorized calculation of the Gabor filter, properly scaled to the size of the object being measured and covering all pixels in the object. The Gabor filter can be calculated at a user-selected number of angles by using the following algorithm to compute a score at each scale using the Gabor filter:

  • Divide the half-circle from 0 to 180° by the number of desired angles. For instance, if the user chooses two angles, MeasureTexture uses 0 and 90 ° (horizontal and vertical) for the filter orientations. This is the θ value from the reference paper.
  • For each angle, compute the Gabor filter for each object in the image at two phases separated by 90° in order to account for texture features whose peaks fall on even or odd quarter-wavelengths.
  • Multiply the image times each Gabor filter and sum over the pixels in each object.
  • Take the square root of the sum of the squares of the two filter scores. This results in one score per θ.
  • Save the maximum score over all θ as the score at the desired scale.

So it looks like you could hack the source code if you wanted to get all angles (since it calculates all then just returns the max), but I can’t personally guarantee it would work.

It’s also worth noting Gabor features were removed in CP 3.0, so when you’re hacking source code start from a 2.2 branch.


Thank you! Sorry I missed that. I may give that a shot. Do you know what the rationale was for removing Gabor features in 3.0?


I think it was a matter of

  • That we didn’t think many users were actually using them
  • Those of us in the lab who look at the relative utility of various features in predicting and measuring morphology weren’t finding many situations where Gabor features were capturing extra information not already captured by Haralick features.
  • IIRC we weren’t sure with how computationally intensive the Gabor features are to compute that we’d be able to port them to 3D compatibility in a way that wouldn’t crash everyone’s computer who attempted to run MeasureTexture, so in light of all of the above it was decided not to bother.

All that to say, if we find a majority (or a dedicated vocal minority who demonstrate a compelling use case) of users who really wanted them in 3.0, they could potentially appear again.


Interesting. I suppose I may not be using the tools correctly, or I don’t fully understand Haralick textures. Basically, I’m trying to quantify the anisotropy of texture. Is there a better way to be doing this?