I ran GLCM on a NASA MODIS Aqua Level 2 chlor_a band using the SNAP GUI. The generated bands appear to use -32767.0 for ``No Data Value’’ but properties have it set to 0.0.
in the properties, you can only change the definition of the NoData value (what pixel value is shown transparently by SNAP). Setting another value does not reclassify existing values.
You have two options
- reclassify the output: -32767 to 0
- define 0 as NoData in the input product and repeat the GCLM (haven’t tested but should propagate how NoData values are written in the outputs).
I have been changing the “No data value” in properties (otherwise the image views are useless), but GCLM generates multiple output bands (I usually get interrupted before I’m finished; in classroom setting pre-COVID-19 results in students checking their phones). The values in the output bands are not in the same units as the input, so GCLM shouldn’t propagate the “No data value” of the input bands but instead supply a value appropriate to the output data.
I see, thank you for the explanation.
Is reclassification in the band maths an option?
IF texture = -32676 THEN 0 ELSE texture
Ideally, algorithms should set an appropriate no-data value when the computed product has different units/scale from the input. For teaching, reclassification might be a way to add interest by introducing band maths.
I agree.
As the textures are probably stored as 16 bit signed integer, the only reasonable NoData values is negative one because 0 is a valid output of the GLCM.
Hi,
I am using Sentinel-1 GRD data with EW swath
I am setting the no data value while mosaicking to -9999 using gdal_translate. Then, I clip a specific region of the mosaicked data (as shown Fig 1, with no data -9999).
1.Does No-Data needs to be redefined everytime before I run the GLCM analysis in the GPT()?
2. If I want to batch process the GLCM step, does the Raster>Data Conversion>Set No-Data Value function will allow changing the no-data to correct value and provide the correct GLCM analysis?
Fig 1
On opening the clipped product in SNAP toolbox, the no data value used is selected and the default SNAP value is set to 0 (Fig 2).
Fig 2
When I change the No-Data Value in properties of the raster within SNAP toolbox, only clipped region is now shown with correct No-Data value -9999 masked (Fig 3).
Fig 3
Even though the true nodata value as set during mosaicking is -9999, if I run GLCM on Fig 1, with default SNAP no-data value of 0, the GLCM Contrast shows as below (Fig 4)
Fig 4
Now on running GLCM on Fig 3, GLCM Contrast shows the following data (Fig 5)
Fig 5
Again at this step, SNAP resets the no data value as 0 within the properties of the GLCM Contrast band and on manually changing it to -9999 removes the border currently visible in Fig 5 of the Contrast raster.
Any guidance or help will be appreciated
Thanks
Could it be that contrasts of Fig4 and Fig5 are the same but only displayed differently because of the high contrats along the edges? You can check using the Color Manipulation tab and set the same min/max values for comparison.
Or will the high values along the edges distort your result in a way?
Hi @ABraun,
On setting the color range of min:0 and max:521.875 (one of the raster range) for both Fig 4 and Fig 5, the results in contrast GLCM band are still different.
NoData in properties: 0
NoData in properties:-9999
hmm, I would have expected that the results are the same at least.
Does it work when you manually assign the NoData value back to -9999 in the graph builder?
Hi @ABraun,
Yes, it works when I set the no data value in GPT using the below workflow Figure A
Figure A
The range is correct in the color manipulation tab: 0 to 521.875 (though within the properties of GLCM Contrast band it still is set to 0, but the processing is done with -9999)
Comparison:
The top figure is from NoData in properties:-9999 and bottom figure is Set No Data in GPT workflow for GLCM texture generation (Figure A)
So it would be nice for future versions to be able to set a nodata value for the GLCM output?
Yes, I think right now the way SNAP is setup is that it processes using NoData value set to 0, unless specifically setup in properties or as a Set NoData workflow node prior to feeding in GLCM or any other processing node.
Do you think using Set NoData workflow node during pre-processing of Sentinel-1 GRD product is necessary if you want nodata to be a different value for e.g. -9999 or NaN?
at the moment I would say yes.
But as there are also problems with 0 in GLCM outputs for the supervised classification (here or here), this might be something for future versions.
@lveci @jun_lu Do you think this could be implemented? After the computation of GLCM 0 is automatically treated as NoData. This is often not the case when the respective texture is simply low, e.g. zero anisotropy. It would be nice to have a user-defined nodata value for GLCM outputs.
Thanks Andreas for your help, this discussion has helped confirm few things as well as shown certain improvements which we might see in future versions of SNAP toolbox 
GLCM has been modified to allow users specify the no data value they want. The default no data value is -9999.0. The fix should be available in the next release.
2 Likes
Thank you. Small refinements like this can make a big difference, especially for new users and presenters or video tutorials.
1 Like
That’s great indeed, thank you!