Interferogram averaging for DEM generation

I wondered if it’s possible (and reasonable) to calculate multiple interferograms and average them for later phase to elevation calculation.
I have Sentinel-1 A/B interferograms (6 days temporal baseline each) in an arid region with high coherence. I would like to exclude atmospheric effect by a combination of interferograms. But I struggle to do it in SNAP.

When would be the best step to do the averaging?

  1. Directly on the filtered interferograms (I doubt that this makes sense)
  2. After unwrapping (how to coregister?)
  3. Or directly averaging the DEM products (tried that, no good results)

Has anyone experience with this?

1 Like

But Why you don’t calculate the error of each DEM, reaching the best one,

In case [quote=“ABraun, post:1, topic:4491”]
I would like to exclude atmospheric effect by a combination of interferograms. But I struggle to do it in SNAP.
[/quote]

I think already removing the atmospheric effects in SNAP is still not highly precise developed (personal opinion)

I agree. For this very reason I would like to make an “ensemble DEM” out of many interferograms, thus minimizing the effect in the single images.

1 Like

Did you try averaging at the end when you have computed the DEM ?

In my opinion it’s less painfull to do it that way instead of manipulating interferograms…but i’m not sure.

yes, I averaged all DEMs in the end as a test, but the result was awful. It kind of combined all the errorneous areas instead of averaging them out.

Hmmm okay. Somewhere it conforts me because I have the same results…

Personnaly I have already problems to coregistrate preciselly a S1 pair.

Then I tried avering interf but it’s a pain in the ass and unfortunately it add errors in some places instead of averaging…as you did in final DEM.

If you find an idea to correct these atmo problems, I’m very interested :slight_smile:

For averaging InSAR-pairs the baseline-dependency should be taken into account. @mfoumelis could you comment?

thank you for the hint. I’m still open to suggestions.
Can you recommend literature regarding baseline dependency?

A quick search found this:

1 Like

Can I coregister my intensity images and save the Look-up table (LUT) in SNAP? I could then apply this LUT to the unwrapped phases for their coregistration.

It would be good but sadly it’s not possible at the moment.

alright, thank you for the quick answer.

do you have an idea how i could co-register unwrapped interferograms in SNAP?

If they were coregistered to the same master initially then you could use merge or create stack. If they all have different masters then you may need to terrain correct and then create stack. Depending on how accurate the geolocation is you could also create stack with resampling but, be careful this doesn’t ruin the phase.

The safest way would be to coregister all of the products first but currently you can’t do different combinations of interferograms. We’ll be adding this functionality next to allow selecting the interferogram pairs based on a baseline plot. It would be helpful to hear your use case so we have can make sure it’s covered.

5 Likes

thanks for the suggestions.

I initially wanted to average different interferograms of a InSAR stack.
Master-Slave1
Slave1-Slave2
Slave2-Slave3
and so on.

Currently, only this formation of interferograms is possible
Master-Slave1
Master-Slave2
Master-Slave3

What you suggest would be great, namely that different product pairss in the stack could be used.

Each of the interferograms could be unwrapped in SNAPHU but the SNAPHU import woudn’t allow to re-integrate them into the original stack - or is this possible?
Edit: I just tried it and it works - great!

  1. importing each of the unwrapped interferograms chosing the original stack as a reference.
  2. stacking all imported unwrapped inferferograms with the stacking operator

If now the user could chose which image pairs to take for the interferogram generation I would be really happy :smiley:

4 Likes

Hi ABraun,
I have a similar problem with the post of yours in terms of interferogram averaging and I would like some suggestions because I am still confused.

I have crated an interferogram (for the period between March of 2016 and March of 2017) to find a potential subsidence for my area of interest but it suffers from decorellation and some artifacts due to the atmosphere. So, I downloaded 10 SLC SENTINEL1 images and I am about to produce a series of interferograms and average them out so I can hopefully increase the coherence in the area and reduce the atmospheric effect.

I am thinking of two ways of producing the interferograms and doing the averaging but I do not know which method is the
optimal one.

first method:
interferogram combinations: 1(master) - 2(slave), 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-9, 1-10

second method
interferogram combination: 1-2, 2-3, 3-4, 4-5, 5-6, 6-7, 7-8, 8-9, 9-10

In the first method, we have one master and the other images are slaves and in the second method we have different master images.
So, my question is, which method is the ‘best’ or the most preferable one?

@ABraun , you mentioned in your post above that only the method of one master and mane slaves is possible in SNAP. So, the method with different master images does not work ?

Thank you

I personally would prefer this approach. You have higher chances of reliable results and still are able to merge the results afterwards (e.g. 1-2 + 2-3).
But it is currently not featured in SNAP yet. You can do it manually however with the TOPS coregistration and the graph builder afterwards.
Currently, you need to terrain correct the unwrapped interferograms to have them stacked afterwards for averaging purposes. I am working on a similar topic at the moment (yet nothing to present) and would be interested if you receive good results.

1 Like

Thanks for your quick answer.
I will try this approach and see what I will get. I will post the results on the forum (if they are any good :p)

Dear Andy,

Did you get any new forward step in this processing?

Didn’t undertake anything in this direction, sorry.