GPT graph processing differs from SNAP's

Microwave Toolbox
1

Summary

GPT and SNAP graph processing differs.

Note

The problem I’m about to report was tested in two 64-bit Linux machines (personal and server), with both SNAP 7.0 and 8.0 versions. No divergence was found in these tests.

Problem description

I’ve created this simple graph with SNAP and later modified it by hand in order to make it easier to later GPT processing, it is attached to this post and will be detailed in a moment. Using graphical SNAP client’s batch processing menu yields expected output.

Now I need to automate the process using GPT. As mentioned, the graph is modified, so that inputFile and outputFile variables can be given from comand line:

gpt $GRAPH_FILE -PinputFile=$INPUT -PoutputFile=$OUTPUT

When run, this line outputs no error. The resulting file however differ from the one acquired from SNAP’s interface (using the same graph and input, in batch processing mode). I show you this below:

test_snap
SNAP Interface batch processing output (as expected)

test_gpt
GPT Interface output (wrong)

What is wrong:

  • masked points in the middle of the data;
  • output dimensions are not common to a split S1 IW SLC processed image.

Just by experience I guess GPT is not doing the multilook step properly (horizontal dimension differs from one output and the other). Maybe there is something to do to NetCDF writing, but I do not know exactly how I came to this thought…

Graph file

The graph developed reads an input Sentinel-1 IW SLC file, applies orbit file, does radiometric calibration, file, deburst and multilook, to finally convert the output to dB and save it as a NetCDF4 (we tested both NetCDF-CF and NetCDF-BEAM with the same results discussed above). The graph can be downloaded below:

s1_iw_slc_2_nc.xml (3.0 KB)

Final note

I previously created a topic on this here, but my description of the problem was not proper, since at that time I thoght these blank pixels in the middle of the image were NaNs, while they are actually just 0 valued masked pixels.

2

One should always use the BEAM-DIMAP format for SNAP processing and do format conversion in a separate step. This may or may not have something to do with your case.

3

It looks like the GPT output has been mapped in a way that stretches the X-axis. It could be useful to compare the geolocation metadata and maybe values from both images for a set of locations defined in geo coords. With NetCDF4-CF, there is support for a “fill” value for cells where there is no data. This value is translated by the library to an application-specific missing data code for read and write operations, so you should check the NetCDF-CF metadata.

4

I just tried to split our graph in two steps:

  • Graph 1: reads data, applies orbit file, then deburst, and multilook to finally save output as BEAM-DIMAP;
  • Graph 2: opens generated BEAM-DIMAP and exports results (writes to) NetCDF4.

But the results are exactly the same…

5

When one opens a IW SLC Sentinel-1 data, it is easy to see that the data is originally stretched in X-axis direction. By my experience, this is regularized when the multilook step is performed.

I understand the solution pointed by @gnwiii might be useful to some, to substitute masked values by a mean constant value or so, but it might break my current system. And this problem does not occur when using SNAP directly when the same graph is used.

I do believe it may be a bug in GPT, probably in the multilook step or when writting to NetCDF4.

My problem can be reproduced with any IW SLC Sentinel-1 data and the simple graph I attached to the post.

6

Do both BEAM DIMAP results and the NetCDF4 from BEAM DIMAP have the issue or is it only the NetCDF4 files.?

8

Thanks for yout help, @gnwiii and @mengdahl. My advisor could find this issue here that led us to a solution. Thankfully GPT is working fine, and our graph was actually incorrect.

In the graph XML, the multilook nRgLooks (number of range looks) tag was set to 1 (<nRgLooks>1</nRgLooks>) by default. In SNAP though, this setting it is automatically set to 4 in this kind of input data. So we changed it accordingly in our XML, and now the output comes as expected.

  <node id="Multilook">
    <operator>Multilook</operator>
    <sources>
      <sourceProduct refid="TOPSAR-Deburst"/>
    </sources>
    <parameters class="com.bc.ceres.binding.dom.XppDomElement">
      <sourceBands/>
      <nRgLooks>4</nRgLooks>
      <nAzLooks>1</nAzLooks>
      <outputIntensity>false</outputIntensity>
      <grSquarePixel>true</grSquarePixel>
    </parameters>
  </node>

This discussion can be closed now!

2 Likes