I do not know what is going on with your error, but speckle filtering, GLCM and H-alpha etc. should be performed before terrain correction. TC resamples the data and changes the original statistics leading suboptimal/wrong results.
about the non-classified areas: They fall below the confidence criterion (threshold 0.5), please have a look here:
thank you for the advice, I made terrain correction and I obtained better results!
Okay, thank you! Then if I need a KNN or a RF classification I had to use another software?
no, the classifier just does not find a class with a high confidence.
You can right-click on the results raster and lower the threshold in the valid pixel expression (or remove the expression completely) to have a class assigned to all pixels regardless of the confidence.
I’ve figured out the problem: I was passing too many features to the classifier. Now with less features it works, as you can see
thank you for the clarification, I didn’t know that.
What features (or how many) did you use before and with which number did it work?
I used the bands produced by the pre processing of the image, the bands produced by GLCM (all the available bands), and the 3 bands from H-Alpha decomposition. More than 40 features (I think they were too much).
Now I only included the bands produced by the pre processing. I’ll try by doing a PCA on GLCM and add PCA to the features of my classification.
Is this workflow right? I’m new to this and I’m not always sure of what I’m doing
To be honest, I would have expected the Random Forest algorithm to “sort out” the unnecessary features (or at least deal with the redundancy inherent in the input data).
How many trees did you use? If you use more than 40 features, processing at least 100 trees would make sense to fully exploit the principle of permutation of the features.
But as a work-around, reducing the number of input rasters by applying a PCA is totally fine.
I was using the standard setting (10 trees), but now I tried with 200. Passing the speckled image, the GLCM bands and the H-Alpha bands to the classifier, I still have the same problem of unclassified pixels.
okay, in that case I don’t have an explanation, sorry
Thank you anyway for your time!!
I made a lot of tries passing different kinds of raster to the classifier. The problem of NaN pixels appears only whenever I give glcm bands to the classifier (even only one). My question is: is there something I have to know (such as some settings I have to modify) about glcm generation? I kept the default settings in the box.
Might be an issue should be checked up, Does GLCM, has any source of NaN?
that is what I suspect as well. Some textures derived by the GLCM module produce NaN pixels. You can have a look if they coincide with the pixels which were not classified.
If so, you have to uncheck the option in the band properties which assigns 0 as no-data and save the product. The corresponding pixels are then black.
I have been naive and I didn’t see that the non-classified zones are NaN in GLCM. So there’s some option in the GLCM box which masks out these zone (mainly seas). could someone explain which is this option?
If I remember correctly, they are not NaN but simply 0 (which is defined as nodata in the properties). If you unckeck the use of nodata and save the product again, the classifier might handle it.
It finally works! thank you all very much !
so making the NaN pixels in the texture rasters to 0 has solved the error?
In the properties I set the NoDataValue option as -1 instead of 0 and I solved the problem