TOPSAR Coregistration

Hi All,

For S1A data processing, are the two steps Range-Shift and Azimuth-Shift required after the Back-Geocoding?

If yes, what are the improvements of those steps?

Thank you,
Kang

1 Like

Range and Azimuth shift apply the enhanced spectral diversity (see references).
Basically it takes advantage of the overlap between bursts to fine tune the coregistration. Generally the backgeocoding is accurate and the ESD can provide a pixel or sub-pixel shift to improve the coregistration.

P. Prats-Iraola, R. Scheiber, L. Marotti, S. Wollstadt, and A. Reigber, “TOPS interferometry with TerraSAR-X,” IEEE Trans. Geosci. Remote Sens., vol. 50, no. 8, pp. 3179–3188, 2012

R. Scheiber and A. Moreira, “Coregistration of interferometric SAR images using spectral diversity,” IEEE Trans. Geosci. Remote Sensing, vol. 38, no. 5, pp. 2179–2191, July 2000

1 Like

Thank you for the explanation.

Hi Luis,

Being interested in TOPSAR coregistration, I’m trying to perform the coregistration between 2 SLCs, namely:

  • S1A_IW_SLC__1SDV_20150928T135959_20150928T140029_007916_00B0DE_EDEE
  • S1A_IW_SLC__1SDV_20151022T135959_20151022T140029_008266_00BA58_71BD

For that matter, I defined the following processing chain by means of the Graph Builder tool (Graph_GRDH_IW_Coregistration_FromSLCSDV_TOPSAR_CoPolVV_UTM_DIMAP_Intensity_v1.xml (22.1 KB) )

Afterwards, the XML file has been used as input parameter of the GPT command launcher. Unfortunately, I encountered the following warning message :
java.lang.IllegalArgumentException: The specified region, if not null, must intersect with the image`s bounds.
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2069)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:420)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:406)
at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:442)
at org.esa.s1tbx.sentinel1.gpf.TOPSARMergeOp.computeTileInOneSwathFloat(TOPSARMergeOp.java:712)
at org.esa.s1tbx.sentinel1.gpf.TOPSARMergeOp.computeTileStack(TOPSARMergeOp.java:629)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:85)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2085)
at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:420)
at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:406)
at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:73)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at com.sun.media.jai.util.RequestJob.compute(SunTileScheduler.java:247)
at com.sun.media.jai.util.WorkerThread.run(SunTileScheduler.java:468)

Do you have any idea of the problem ? Moreover, have you any recommendation / modification to suggest according to my xml file?

I precise that I got the latest version of the SNAP software (2.0 Beta 8) for Linux64.
The configuration parameters are as follows:
Ubuntu, 16 Go RAM, 8 cores.

Kind regards,

Yannick

First of all, monster graphs are never a good idea. You’re trying to do too much all at once. Break it down.
You can’t apply the TOPS merge with multilook and terrain correction between the Deburst.

Do deburst and then merge. After this, apply the multilook, speckle filter and last terrain correction.
If all you wanted was the coregistered GRD, it would be simpler to apply the SLC to GRD graph then terrain correct. You could then create stack or coregister.

1 Like

Hi Luis,
Dealing with the TOPSAR coregistration previously mentioned, I solved the problem thanks to your suggestions.
By now, I’m further interested in coregistrating multi-sensor SAR images (Sentinel-1 with TerraSAR, or Cosmo-Skymed) by means of the SNAP toolbox (through either HMI or GPT command line).
For that matter, what kind of processing chain would you recommend ? For instance, have you any idea of an XML graph to coregister Sentinel-1 and TerraSAR-X images ?

Best regards,

Yannick

I would recommend orthorectifying both separately using the same DEM. If everything is done correctly, the images should match 1-to-1.

What about resampling for both images ?
How you would precisely perform such orthorectifiction in order to allow superimposition of these couple of images ? What kind of processing you would successively apply?

If you want to stack the all images later you should process the images to the same pixel-size. I haven’t tried this myself so I cannot give you a full processing-chain, but in principle it should work.

Thanks for your answer, I really appreciate.
So finally, the following processing chain as available in the “Coregister” SNAP GraphBuilder:

“ProductSet-Reader --> CreateStack --> GCP-Selection --> Warp”

should be relevant in order to coregister multu-sensor images, shouldn’t it ?

Cheers

If you resample in the createstack step, your phase may get damaged. We’re working on a generalized backgeocoding similar to the TOPS one but for other missions. This may give a better result.

1 Like

I don’t think co-registration between missions will work unless the incidence-angle is the same. Terrain correct separately using the same DEM, with good orbits that should work well.

Many thanks guys!
Luis, you talk about a generalized backgeocoding for other missions. Have you any idea of the availability of this new functionality? I mean in the next few months or by next year?

Hi All,
I tried to coregister the IW2 sub-swath of Sentinel-1 IW SLC TOPSAR data with another IW2 sub-swath of a Sentinel-1 TOPSAR product which is a S1 TOPS Slice Assembly product, using the S1 TOPSAR Coregistration operator and I got the error ‘ raf == null!’. What could be reason for this error?
Is there any solution to avoid this error and to do a successful coregistration of TOPSAR Slice Assembly product with another TOPSAR data using S1 TOPSAR Coregistration operator?

i am trying to coregister sentinel 1 data but error occurs and says “received in null tile”. help me with this