DATA Conversion issue!

Microwave Toolbox
#21

But now it is only visually gone.
You can remove the valid pixel expression on the new band and update the colour interpretation. You can inspect the values with the Pixel Info view.
After removing the expression I get this result
**removed image**
After Updating the colour interpretation I see this
**removed image**

1 Like
#22

Thanks Marpet! I guess I am missing one step here. How can I save the color changes made in order to become effective on the image (in geotiff)?

Thanks again!

#23

the color adjustment doesn’t change the raster values at all. It just defines which pixel value is displayed in which colour. So there is actually nothing to save that affects your exported data.

1 Like
#24

So, does that mean that I can not get a separate code for the image background of my geotiff output? I just don’t want the background carries the same value as water or land does.

Thanks .

#25

if the pixels have different values within SNAP (different colours couldn’t be assigned if this wasn’t the case) these should also remain after the export to GeoTiff. So first you need to get a three colour image like demonstrated in marpet’s post and then export shouldn’t be no problem.

1 Like
#26

All the discussion we’ve had here so far was about the problem of data conversion. To quickly go through it:

  • the band math produced in SNAP is our ideal where water carries 1, land 0, and background NaN. So far so good!

  • The problem starts after data conversion: the image background also gets a value of water (1). marpet fixed the issue (feq(Sigma0_HH_Dissimilarity, 0) ? 0 : Sigma0_HH_Dissimilarity/10<1) , where now I can get the water in 1, land in 0, but the background also carries value of 0 as land does!

  • So the second band math recommended (feq(Sigma0_HH_Dissimilarity, 0) ? 128 : Sigma0_HH_Dissimilarity/10<1) resulted in the same background issue we had at the beginning. So, that’s why the color manipulation was suggested then. However, it can not be saved and the final geotiff product would remain the same.

The objective is to produce water mask maps that water , land, and image background carries a different code.

#27

I think you do it way too complicated. Don’t apply the terrain correction too early as it tilts your image and you introduce the background area.

What works for me (I just did it in the GUI but it shouldn’t be a problem with a graph file as well):

  1. Calibration to Sigma0, speckle filtering and subsetting (could be any other product as well):

    grafik.png1399×840 1 MB

  2. Applying a threshold for water:

    This gives me this result

    grafik.png1436×868 49.8 KB

  3. Range Doppler Terrain Correction with output GeoTiff:

    grafik.png597×713 9.85 KB
    >
    grafik.png594×715 23 KB

This is how it looks in SNAP

grafik.png1357×841 71 KB

And how it looks in a GIS:

grafik.png1185×826 770 KB

Or with different colors:

grafik.png1202×830 1.55 MB

2 Likes
#28

ABraun, Thanks for sharing this. But, my image processing order is a little bit different, CALIBARAION> TC> TEXTURE> BAND MATH

I am getting water mask out of texture bands which have worked well. In so doing, I need to get the ortho first, produce the texture then. Only issue is for the geotiff products obtained from data conversion.

#29

Why not putting the Terrain Correction at the end if this solves your no-data problem?
Nothing would change and (like speckle filters) texture calculation is more effective on the unprojected data in slant geometry.

Calibration > Texture > Band Math > Terrain Correction to GeoTiff

1 Like
#30

Because I have pre-processed all my datasets :disappointed_relieved:, and band math was the last step. But, if your recommended approach solves the issue, I will rerun it. Thanks a lot!

#31

When you use the data conversion on the created mask then you should consider these settings:

When you move the mouse over the image you should still see 3 different values. 0, 1 and 128,

The colour interpretation is an other issue. Probably we are doing very good in this case.
But you can manually adjust it. Also if you load your mask into an other application the colour interpretation is up to the application.
If you just want an coloured image of mask you can right click in the image and choose export view as image. Chose full scene and full resolution. Now the colours should be preserved even if you look at it with a simple photo browser.

1 Like
#32

Terrain-correction should be the last step. It resamples the data so the statistics of the data change, which will affect for example texture measures. Doing terrain correction earlier might work depending on the circumstances, but it’s certainly not the optimal/correct solution.

1 Like
#33

This is the change I’ve made to my processing order: Radiometric (in BEAM-DIMAP)> Texture (in BEAM-DIMAP)> Band Math (convert band) >> TC (in geotiff)

#34

It’s advisable to do all processing in DIMAP and export to GeoTiff as the last step.

1 Like
#35

Probably thats the best place to refer to a similar problem. Here is the picture:

pixel_values.png1282×693 193 KB

This sar product is loaded, thermal noise is removed, radiometricaly calibrated, convert to db scale, speckle filtering and terrain corrected. You will see a white background which is introduced during the image enhancement. The sentinel1 SAR data have a black background which is the no data value and equals to 0. After enhancing the image, 0s are taking the maximum value of the raster. Since i have a 16bit integers (i rescale later) the 0s are now 2**16= 65536. Is there any way via snappy to set 0s as no data value from the beginning of the image enhancement so that those values will not be processed at all? Are some other work around that the background will remain black?

#36

Right click on the band name, select Properties, and select No-Data Value Used. Then the 0’s in the image will be treated as No-Data Value.

#37

Thank you junlu for the help. Is there however a way in snappy (via python ) by setting a special argument? I have not find this yet…

#38

To set this property in snappy for a band you can do the following:

…
result = GPF.createProduct(…)
band = result.getBand(“band_1”)
# or
# band = result.getBandAt(0)
band.setNoDataValueUsed(True)
# optionally you can change the no-data value
# band.setNoDataValue(0.12345)

#39

many thanks marpet!

From the qualitatively point of view, the 0s outside of the main image (the background) are no valid pixels. However there are several blocks of 0s inside the image as well. Should I interpret that as 0 backscatter and hence, the area is ice free? Or could be that something happen in the measurement and those pixels are really invalid?

#40

Maybe the valid pixel expression is your friend. here you can define an expression what should be valid and not a single value which is not valid.

band.setValidPixelExpression(‘band_1 < 65000 && band_1 != 0’)

You can set this also on you input product with snappy and hopefully it is considered by the following operations. But I don’t know radar processing very well.