strange patterns in the interferograms from ALOS2 ScanSAR images

[RShamshiri]

Hello everyone!

I am running alosstack on a couple of ScanSAR (VBS) images using ISCE2 (version 2.5.3). The interferograms look strange! There are parallel ramps in some sub-swaths, that there are not when processing them with SARScape! I attached one of them. I am wondering what is the reason and how can I resolve this problem!

Kind regards Roghayeh

[EJFielding]

Hello Roghayeh,

I have never seen that kind of problem before. Are you applying an ionospheric correction? IWhat does the burst overlap file show? Maybe the burst overlap is small and the burst overlap filtering is not working well.

I don'y know how often @CunrenLiang reads these issues. He would know more about this than I do.

You should also upgrade your ISCE2 installation to the more recent version v2.6.0 or 2.6.1. It is possible that this was fixed since your older version 2.5.3.

All the best, ++Eric

[CunrenLiang]

Hi Roghayeh,

This was caused by some bad azimuth offsets used for resampling in coregistration. You can go to one of the subswath processing folder, e.g. f1_/s

You will see ampcor.off and cull.off. Originally estimated offsets are in the first file. Selected offsets used for resampling are in the second file. If you plot azimuth offsets, you will see results like in the following figure

So the good azimuth offsets were not correctly picked up by the program. You can do it manually. After you prepared cull.off. You can rerun from step form_int.

Cunren

[EJFielding]

The figure is from this paper:

Liang, C., and E. J. Fielding (2016). Interferometric Processing of ScanSAR Data Using Stripmap Processor: New Insights From Coregistration, IEEE Transactions on Geoscience and Remote Sensing 54, no. 7, 4343-4354, doi:10.1109/TGRS.2016.2539962.

[RShamshiri]

Hi Eric (@EJFielding) and Cunren (@CunrenLiang)

Thank you very much for your comments. I looked into the cull.off files, and found out that for some cases the manual selection of the offset works very well. Here is one example:

but for some other cases (probably when the coherence is poor), it is not easy to find the best offset. For instance, here are the azimuth offsets selected by the software (cull.off) for two images (201213 - 201227), which their interferogram has the residual ramps in the first sub-swath:

when the offsets are scattered like this, it is also challenging to find out the "cull.off" of which image should be modified! especially when we have a stack of small-baseline interferograms.

I tried to remove some scattered offsets. Although the ramps in the new interferogram were reduced, some ramps were still there. I was wondering if there is any solution for this issue.

Kind regards Roghayeh

[EJFielding]

Hi Roghyeh,

It looks like you have a pair with very low matching coherence. I see it is from the winter (I am assuming you are working in the Northern Hemisphere), so it might have snow cover. It may not be possible to process that pair. In the past, there was a way in the old ROI_PAC package to run the "ampcor" program with a very large number of matching windows, but I am not sure how to do that in the alosStack workflow. You might want to leave that date out of your stack.

All the best, ++Eric

[RShamshiri]

Hi Eric,

Many thanks for your response.

yes, the matching coherence is low because of snow cover. However, I do not see these ramps when I create the interferograms using SARScape. So I was wondering whether modifying the setting parameters would help.

Kind regards, Roghayeh

[CunrenLiang]

Hi Roghayeh,

I saw you plotted the offsets with range pixel number as abscissa. Perhaps you can also try azimuth pixel number. You can also look at the interferogram/coherence to see where it has low coherence, and then remove offsets in those areas first. Note that the range/azimuth pixel number are based on single look SLCs, but the coherence and inteferogram are multilooked.

Cunren

[CunrenLiang]

PS: the line interval of mosaicked interferogram/coherence are line interval of first swath number of looks. You can also use insar/_az.off to get rid of bad offsets, they do not differ much. _az.off/_rg.off are offsets computed using geometry. This is the robust way of computing offsets, but it might not be good for L-band, since ionospheric shift in azimuth can be significant and thus leads to significant decorrelation if using geometry offset.

[RShamshiri]

Hi Cunren (@CunrenLiang),

Many thanks for your feedback. They helped a lot!

It worked for some interferograms, but I was unable to fix the coregistration problem for interferograms made with one image that was likely acquired on a date with significant ionospheric activity. Here is one of the interferogram and coherence maps created with the super-master image:

and here are the azimuth offsets (from the "cull.off" files) vs the (multilooked-) line and sample number for different sub-swaths (S1 (the leftmost in the ifg image) to S7 (the rightmost in the ifg image)):

I have no idea how to detect and remove the outliers! Could you kindly help me with that?

Kind regards, Roghayeh

[EJFielding]

It looks like you do have a very strong ionospheric variation on that date. The offsets as a function of line show the pattern of a change in offsets by about 4-5 pixels between lines 0 and 2000, but then the opposite trend after that. As far as I know, the offset culling and registration adjustments in the alosStack processor assume that a linear trend is sufficient, but that is clearly not true for this case. The streaks in your coherence map in the lower right part of the figure suggest that there is even more rapid variation in the ionosphere in that area, so I suspect that you won't be able to get good interferograms with this scene.

[CunrenLiang]

I agree with Eric.

The ionosphere in this pair is too strong to correct for. The difficulty is mainly the spatially fast varying ionosphere patterns plus its large magnitude. Coregistration is a big problem even for strip map mode data in this situation. The range split spectrum method also cannot capture the spatially fast changing component of the ionosphere.

This means either or both of the images have strong ionospheric effects. I would not use it.

发件人："Eric Fielding" @.> 发送日期：2023-01-05 04:36:04 收件人："isce-framework/isce2" @.> 抄送人：CunrenLiang @.>,Mention @.> 主题：Re: [isce-framework/isce2] strange patterns in the interferograms from ALOS2 ScanSAR images (Issue #565)

It looks like you do have a very strong ionospheric variation on that date. The offsets as a function of line show the pattern of a change in offsets by about 4-5 pixels between lines 0 and 2000, but then the opposite trend after that. As far as I know, the offset culling and registration adjustments in the alosStack processor assume that a linear trend is sufficient, but that is clearly not true for this case. The streaks in your coherence map in the lower right part of the figure suggest that there is even more rapid variation in the ionosphere in that area, so I suspect that you won't be able to get good interferograms with this scene.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[RShamshiri]

Hi Eric (@EJFielding) and Cunren (@CunrenLiang)

Thank you very much for your feedback. I had to exclude the images affected by significant ionospheric variations. However, even for the pairs not affected by such variations, I'm still facing difficulties in achieving accurate co-registration. Here is one interferogram and its corresponding coherence map between images 210418 and 210502:

After following your suggestions and making several attempts to remove the outliers, I obtained the following maps:

And here are the azimuth and range offset plots before (black) and after (red) manual outlier removal for both images: 210418: 210502:

For the same pair, I have the geocoded coherence map produced with SARScape (clipped to the AOI): and here is the geocoded and clipped coherence map produced with ISCE2:

The coherence map created by SARScape does not show the same discontinuity between S3 and S4 as seen in the ISCE-generated map! In addition, the coherence values, in general, seems higher in the SARScape map compared to the ISCE-generated map!

I looked into the "estimate_slc_offset.py" and "estimate_swath_offset.py" scripts to see if adjusting the parameters may solve the issue, but the improvement was very limited! I wonder what might be the difference in the methods!? Could you kindly help me with that?

Kind regards Roghayeh

[EJFielding]

Hi Roghayeh,

I don't know what parameters you can adjust to get better results, but I can see in your offset plots that several of the plots of Az offset vs. line have two parallel lines with many offset values. This indicates that the matching is finding matches on two different locations where the full-aperture focusing has high amplitude. Only one of those two locations can be correct. When you culled the outliers, you ended up with a line of points between the two lines of many offset values, which is not going to be the optimum offset for the co-registration. This likely explains why you ended up with poor coherence in the interferogram.

I am not sure what manual culling you did, but you should try to get the culling to select one of the two lines, not something between the two lines. It might not be obvious which of the two lines has the greater number of points, so you might need to try both of them.

[CunrenLiang]

Eric is right. The problem is still culling the azimuth offsets. If you are unable to determine the correct offsets, you can use alos2App.py to calculate the geometrical offsets. The estimated offsets should not differ a lot from geometrical offsets.

To calculate the geometrical offsets of a subswath, you can run alos2App.py and specify the swath number in the input file. The computed azimuth offset is then in 'insar/date1-date2_1rlks_14alks_az.off'. Note that you can only compute geometrical offsets for one subswath; otherwise the file is for the mosaicked subswaths.

[RShamshiri]

Hi Eric (@EJFielding) and Cunren (@CunrenLiang)

Thank you very much for your feedback!

Eric, to remove the remaining outliers I plot the offset values from "cull.off", define two lines above and below the offset values with higher density and remove those falling outside the buffer! but when the offset values are scattered, it becomes challenging to accurately define the lines, especially in stack processing if none of the images of a pair is the reference (super-master) image!

Cunren, as I am processing a stack of images, I ran the same scripts (alosStack) but using the geometry-based method for the co-registration. and I got "cull.off" files within each sub-folders for sub-swaths ("/dates/yymmdd/fxxxx/sx"). The coherence looks very good now!

I then tried to implement your suggestion. I fitted a line to the geometrical offsets and defined two lines above and below it and removed the cross-correlation offset values that fell outside of these lines! Here are the plots showing the offset (in azimuth direction) values before (left) and after (right) removing the outliers for one sub-swath: (black dots: the geometrical offsets, blue dots: the cross-correlation offsets (cull.off), red dots: the final cross-correlation offsets)
and here is the coherence map:

I was wondering what is the advantage of this method (the combination of geometry and cross-correlation) over the geometry method alone, assuming I have correctly applied your comment. :)

Kind regards, Roghayeh