I’m afraid the quality of your inteferogram is not sufficient to generate a fully covered DEM. As you see, there are larger areas in your image with low coherence (no fringes). During the unwrapping process, thesse areas are not correctly converted to an absolute phase. What parameters (TOPO, DEFO, SMOOTH) did you use for unwrapping?
What is the temporal baseline of your image pair?
To get a proper DEM you need high coherence throughout the entire image.Can you please post an image of your coherence (including the color bar)? Additionally, the incidence angle and the perpendicular baseline (can you please check how large it is?) play a role.
Thank you for your reply.
The parameter that I use is DEFO.
Temporal baseline: 6 days (Master:30-03-2019 Slave:24-03-2019).
Track: 68.
As you see, the coherence is quite low - do you have much vegetation in your study area? The lower half is completely decorrelated.
You can use the InSAR stack tool to get information on the perpendicular baseline.
Although it will probably not change very much, you should use TOPO in the unwrapping settings for DEM generation 
Thank you. That low coherence may be due to the temporary basis or the type of soil ?. It’s a maritime coast, that’s why there is a lack of coherence in the lower part (I must remove it). Then there are mountains / elevations of sand, lagoons and fields.
hello, is it true that SNAP has released a plugins for unwrapping? so we didnt need the virtual machine to unwrap? Plus, i found a video on youtube on how to use the plugin. Link below: https://www.youtube.com/watch?v=sH4Uhsgmpak
I have follow the tutorial and it runs exactly like the video. I have been running it for 6 hours and didnt get any result yet. Can anyone confirm that this method is working or not? Thank you.
Yes, indeed, Please take a look at the following post,
But for long time running, Please check up the following things,
SNAP update,
The RAM of your Machine
The processor might also affects,
The memory saving of your Machine
Continuing the discussion from SNAPHU Unwrapping:
E:\SNAPHU\snaphu-v1.4.2_win64\bin>snaphu
snaphu v1.4.2
usage: snaphu [options] infile linelength [options]
most common options:
-t use topography mode costs (default)
-d use deformation mode costs
-s use smooth-solution mode costs
-f read configuration parameters from file
-o write output to file
-a read amplitude data from file
-c read correlation data from file
-b perpendicular baseline (meters)
-i do initialization and exit
-l log runtime parameters to file
-v give verbose output
–mst use MST algorithm for initialization (default)
–mcf use MCF algorithm for initialization
type snaphu -h for a complete list of options
E:\SNAPHU\snaphu-v1.4.2_win64\bin>snaphu -f snaphu.conf Phase_ifg_VV_18Oct2014_01Jan2019.snaphu.img 17618
snaphu v1.4.2
27 parameters input from file snaphu.conf (84 lines total)
only one tile–disregarding multiprocessor option
Logging run-time parameters to file snaphu.log
Reading wrapped phase from file Phase_ifg_VV_18Oct2014_01Jan2019.snaphu.img
No weight file specified. Assuming uniform weights
Reading correlation data from file coh_IW2_VV_18Oct2014_01Jan2019.snaphu.img
Calculating deformation-mode cost parameters
Building range cost arrays
Building azimuth cost arrays
Initializing flows with MCF algorithm
Setting up data structures for cs2 MCF solver
it stucks at here for 1 day. im using i5 8400, 8gb ram running on windows 10. where did i get wrong?
The RAM 8 GB , is not enough, Also the processor might be causes a problem, but coming back to the RAM issue, there are two solutions, first one you could subset your AOI, second one is , increasing the SNAP RAM as explained below by @marpet
Or you could try up both solutions,
For the SNAP Desktop application, you can increase the amount of memory available to SNAP.
In the ‘etc’ folder of the SNAP installation directory, you’ll find a file named snap.conf. Open it in a text editor.
There is the line which starts with ‘default_options=’
In this line you’ll find an option like -J-Xmx5G . Increase the value. You could use something like -J-Xmx13G , if you have enough memory in your computer. By default, it is set to ~75% of the maximum value. This is usually a good choice.
Problem solved!! I just multilook the image before unwrapping. Does multilook cause the result to be different? Im just curious since my system cant run the non multilook image. So i cant tell the difference.
@fakhrul
Multilook decreases the image size quite drastically (depending on your parameters) and also increases the phase quality (lower speckle). In general, it results in Multilook increasing the quality of the unwrapping process while decreasing a lot the processing time.
Except if very high fringe rate, I recommend always multilooking before unwrapping. With low amount of RAM (which is your case), this recommendation becomes a requirement.
2 Likes
as @qglaude answered your question
in here,
That’s mean, the source of your problem in your machine is the RAM, and the processor, So, subset, multilook, increasing the virtual RAM, should be taken in account in your future processing.
I’ve been experiencing a strange error with the unwrapping process that I hope someone can help with. No matter how small I subset and/or use heavy multilooking I keep getting this “Unexpected increase in total cost. Breaking loop” error. I’ve also gone through the trouble doing fresh workflows w/new product downloads on three different machines.
Using the following product pair I took the following steps.
S1B_IW_SLC__1SDV_20190628T014958_20190628T015025_016890_01FC87_FC0D
S1B_IW_SLC__1SDV_20190710T014959_20190710T015026_017065_0201B8_069B
- S-1 TOPS ESD Coregistration
- Interferogram
- TOPSAR Deburst
- Subset*
- Goldstein Phase Filter
- Multilooking*
- Unwrapping error occurs after SNAPHU constructs tiles
*Tried process with & without these steps
Thank you~
have you tried switching between the unwrapping methods (MST/MCF)?
You can delete the temporary products (tiles folder and any data with a cryptic file name) in the snaphu folder, then modify the config file (select MST or MCF) and run the command again. Also slightly increasing the number of tiles could fix the error.
1 Like
ABraun,
Appreciate the quick reply, and thank you for pointing out a much quicker way to retry the unwrapping process! I’ve tried a lot of different unwrapping parameters, but will try more.
Another thing I wanted to bring up, that I only noticed recently, is the bursts looked distorted in the S-1 TOPS Split preview only(IW 2&3 burst 9 were distorted). Just now I went back to see if other granules in the same path/frame were also like this, and they were not. Going to try using a different pair of granules for now and probably try downloading the first pair from scihub.copernicus too. (I normally get everything from ASF, being in California it’s significantly faster. ~10mins vs ~2-5hours)
Thank you again,
Dake
the previews are just a rough estimate of the single bursts. They are more or less equidistant in all SLC products but the single image’s frames can be shifted along-track between images of different acquisition dates.
Hope you manage to complete the unwrapping without errors.
I did just have to sit down and bang my head against the snaphu export parameters. Looking for any advice on attached output, curious if I can avoid some of the tiling distortions even with my limited hardware.
Hope it’s alright to share kmz’s: https://drive.google.com/open?id=1EcH1Oig46QJdwlv6XYMREXEUKlNnV2T7
Thank you again for your help.
they look quite strange (but nice result overall!)
What did you select for
- statistical cost mode
- initial method
- number of tile rows / columns
- row / column overlap
- tile cost threshold
?
Statistical cost mode: DEFO
Initial method: MCF
Tile rows / columns: 80/80
Row / column overlap: 0/0
Cost threshold: 500
I would recommend to reduce the number of tiles to 12/12 and increase the overlap to at least 100. More is advised but it depends on the size of the single tiles (total number of rows divided by the number of tiles) how large you can make the overlap variable. If your tiles are only 50x50 pixels, the overlap cannot be larger and should be in relation to the total size.
1 Like
I would like to see the coherence estimation carried through snaphu unwrapping to the terrain corrected product in SNAP. The coherence image is a useful supplement to the deformation map in assessing data quality and emphasizing discontinuities in the data (faults in the case of seismic deformation.
Did the direction of interferomic displacement reverse between Snap versions 6 and 7? What was up in 6 is now down in 7? Other than installing 7, I had changed coherence window in interferogram formation from 20/10 to 10/3
Maybe has to do with this issue https://senbox.atlassian.net/browse/SITBX-640 ?
Does the processing sequence for radar interfermetry change between v6 and 7? Around the deramp and demod processes?
In v6 I was using the menu steps. In v7 I changed to the Graph Process Tool. Maybe there are difference in default parameters between GPT and the menu steps?