Dear all,
I had one intensity feature that it is stretched (it is between 0 to 255); I applied GLCM on it and in some areas I got NAN values?
Why it is like it?
Cheers
Textures often result in the value zero which is then considered as no data (NaN) by SNAP. You need to un-check this option in the band properties.
Didn’t you report the same here? It would be good to continue in existing topics (as long as they deal with the same problem), to keep the forum clean.
1 Like
The band likely has the no data value set to 0. Before your quantization to 0…255 you may want to change the no data value.
yes I know guys but results do not look logical.
No. Actually band has value and this is strange to me.
can you explain this some more? What happens if you remove the checkbox in the band properties, before the derivation of textures, as @lveci suggested
What value is contained in the NaN parts?
I do not have original data now. I only have quantization to 0…255 ones.
look here:
for two difference classes, I will have zero value; and by this way, using GLCM destroy my classification than helping.
I don’t fully understand. Acutally the GLCM does its own quantization. To my opinion there is no need to convert it to 0-255 before the derivation of textures.
What is the pixel value of the two areas you mention when you remove the no data option?
Both of them are converted to zero. I think the only way is to get data before converting to 0 to 255, then apply GLCM and then apply 0 to 255 (maybe).
yes, probably these two areas were not similar before the conversion to 8bit, but afterwards they belong to the same grey value (the lowest possible), because radar data is not normal distributed. If you use calibrated data, you can also convert to dB to increase the contrasts in low-backscatter areas.
1 Like
I increased the number of quantization level and then it was almost solved.
Dear @ABraun,
-
Did you mean that we can/should run GLCM on dB images (convert bands do dB) instead of running on the linear one?
-
The modification of NaN value in GLCM bands can only be done in Band Properties manually one by one. Can we do it as a batch processing?
Thank you!
no, not necessarily. But the contrasts in low value regions are higher in the dB scale. Accordingly, the computed image textures will be different. The most important thing is that the input data contains no NaN or zero values which result in erroneous texture layers.
If you have many NaN values in the textures, you could indeed give dB images a try as input products because they are less likely to contain NaN values, thus resulting in less NaN values in the textures.
I am not aware of a method to change the NaN properties for multiple rasters at once, sorry.
1 Like
Thanks @ABraun for your promptly reply.
I tried to run GLCM on both Linear image, dB image, and dB image without NaN (unchecked the No data value in the Band Properties). However, the NaN value are still remained in my GLCM results.
This would be a trouble because I am applying Terrain Correction after GLCM analysis (as you suggested in another post), especially the GLCM analysis generate 10 components now in SNAP.
are you sure that no NaN values exist in the initial image? dB of NaN is still NaN
I meant in the power scale image before the conversion to dB.
Otherwise, some patterns just result in 0 texture (e.g. zero heterogeneity) and SNAP thinks 0 is no data, so the option to uncheck the no data value is probably the only solution.
1 Like
Thanks ABraun for your concern.
The power scale image is OK, there was no NaN.
The NaN value appeared in 2 components Sigma0_VH_Contrast and Sigma0_VH_Dissimilarity.
The other VH components or VV polarization components are having their value.
FYI, the NaN pixels appear like salt and pepper effect widely spreaded in the Contrast and Dissimilarity image
Just an update for your information, in another attempt (running GLCM after the Terrain Correction), I found the NaN value in VV_Contrast and VV_Dissimilarity in stead of VH polarization components when running GLCM before Terrain Correction.