Hello, I process SLC images with the following operations: Back-Geocoding, Interferogram, Deburst, Topo-phase-removal, Multilook and Terrain-correction. When I perform these operations in a Snappy script with the default values for each parameter, I get a different coherence result from that given in SNAP using the Graph-builder. I’m trying to understand why.
With the XML graph, I have the default values of the parameters of each operation in SNAP. Please, can you tell me how to get the default values used in Snappy? I use “snappy.GPF.getDefaultInstance().getOperatorSpiRegistry().loadOperatorSpis()” to prescribe these parameters.
Thank you for your help
It would be helpful to see at least some stats for the difference in the coherence result. Small differences would not be surprising as Python and Java may use different numerical representations (32-bit versus 64-bit or even 80-bit extended precision) in some floating point calculations, and may also reorder calculations for efficiency in a way that can produce minor differences.
hello,
the calculation is made from two images that are from Orbit 59 in August 2019:
S1A_IW_SLC__1SDV_20190808T174030_20190808T174057_028481_03381D_484F.zip
/ Subswath IW3, burst 5 and
S1B_IW_SLC__1SDV_20190802T173958_20190802T174025_017410_020BDF_48BF.zip
/ Subswath IW3, burst 1.
With SNAP, I get on the full burst the mean coherence of 0.23 (std dev 0.256) and with Snappy the mean is 0.185 (sdt dev = 0.218).
On my plot, located (3.401155 / 48.580278), I get the mean coherence of 0.324 (std dev= 0.12) and with Snappy the mean is 0.194 (std dev = 0.097).
Thanks for your help
That looks like a too big a difference to be explained by the idiosyncrasies of floating point arithmetic. Can you compare the intermediate results at each step in the calculation to see where the difference originates?
I mainly work with NASA’s OBPG data and tools. For those, the metadata provides at lot of details, including the parameter values used in the calculation as well as the processing history, so can often reveal the source of differences such as you are seeing. BEAM DIMAP files reproduce the OBPG metadata in the .dim files. Although you can view metadata in the SNAP GUI, the .dim files are ASCII text so you can inspect them with just about any text editor and search for particular entries.
You may be able to narrow down the issue to parameter values versus valid data masks by comparing the intermediate images and their metadata.
Thanks for your help.
The discrepancies seem to come from the operation 'interferogram '. I found the parameters in the .dim files and I found some differences, including the parameter “cohWinAz” which is 2 in SNAP and 10 in Snappy and the parameter “subtractFlatEarthPhase” which is false in SNAP et true in Snappy. I will keep you informed as soon as I have corrected this.
hello, in SNAP, “manually”, I did the interferogram calculation with the “Coherence Azimuth Window Size” imposed at 10, as in Snappy, and the coherence is strongly modified: it goes from 0.32 to 0.16. To do this in SNAP, I had to change the “Coherence Range” from 10 to 40 to keep the “Square Pixel”.
What is odd is that in Snappy it is possible to prescribe a “Coherence Range” of 10, a “Coherence Azimuth” of 10 and a Square pixel, see below the list of parameters of the interferogram op. used in Snappy
Thnak you for your help
Hello, I found the origin of the problem: I prescribe a parameter ‘Coherence Azimuth Window’ in Snappy to 2, see below
and this value is not taken in account: it remains at 10 !
Maybe the wording in Python is not correct? Thank you for your help
The parameter names used in GPT (gpt Interferogram -h) and the .dim file, e.g., “cohWinAz”, agree. Have you tried using those names in the snappy parameters hash?
1 Like
Thank you, I fixed parameter names in Python as you can see below
but “CohWinAz” (2) and “CohWinRg” (40) are still not well taken into account, even with a “squarePixel” = False, they remain to 10!
.
with tiny ones, the parameters cohWinAZ et cohWinRg have been taken into account. The problem is solved, thanks 
Can you explain “tiny ones”? I’m glad the problem is solved, but I’m not familiar with the expression and there will be others with the same problem who will need the solution.
I guess he means lower case letters (cohWinAz instead of CohWinAz)
Exactly, sorry about that expression. Nevertheless, it is strange that the default value of this parameter cohWinAz in GPT is 10 while in SNAP it is 2.