Warp error during coregistration of subsetted Sentinel-1A data

s1tbx
#1

coregister.xml (2.8 KB)S1_runfile.log (32.6 KB)subset_calibration_multilook.xml (2.6 KB)terrain_correction.xml (3.0 KB)

Dear All,

I have been trying to create a stack of coregistered Sentinel-1A data using NEST and S1TBX. I have found an issue with the Warp operation when I attempt to stack subsetted S1A_IW_GRDH_1SDV datasets. I get the following error message during the Warp operation:

“Cross Correlating 1 of 8 Sigma0_VH_slv2_28Mar2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 2 of 8 Sigma0_VH_slv6_15May2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 3 of 8 Sigma0_VH_slv14_19Aug2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 4 of 8 Sigma0_VH_slv8_08Jun2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 5 of 8 Sigma0_VH_slv12_26Jul2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 6 of 8 Sigma0_VH_slv10_02Jul2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 7 of 8 Sigma0_VH_slv4_21Apr2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cross Correlating 8 of 8 Sigma0_VH_slv16_12Sep2015… 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Warp: operation “Warp” requires parameter at index 0 to be non-null.
Warp: operation “Warp” requires parameter at index 0 to be non-null.
org.esa.beam.framework.gpf.OperatorException: Warp: operation “Warp” requires parameter at index 0 to be non-null.
at org.esa.beam.framework.gpf.graph.GraphProcessor$GPFImagingListener.errorOccurred(GraphProcessor.java:373)
at com.sun.media.jai.util.SunTileScheduler.sendExceptionToListener(SunTileScheduler.java:1646)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:921)
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.beam.framework.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:387)
at org.esa.beam.framework.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:365)
at org.esa.beam.framework.gpf.internal.OperatorImage.computeRect(OperatorImage.java:69)
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)
Caused by: org.esa.beam.framework.gpf.OperatorException: Warp: operation “Warp” requires parameter at index 0 to be non-null.
at org.esa.nest.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:431)
at org.esa.nest.gpf.WarpOp.computeTile(WarpOp.java:534)
at org.esa.beam.framework.gpf.internal.OperatorImage.computeRect(OperatorImage.java:79)
at javax.media.jai.SourcelessOpImage.computeTile(SourcelessOpImage.java:137)
at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
… 11 more”

I have attached the logfile from my processing with details of the input products and processing parameters used, plus the XML graphs.

  1. The initial workflow for each input dataset is as follows: “Read -> Subset -> Calibrate -> Multilook -> Write (BEAM-DIMAP)”.
    I use an input POLYGON to define the AOI for the Subset operator.

  2. These subsetted input datasets are then coregistered to create a stack in the second workflow:
    “Read Product Set -> Create Stack -> Select GCPs -> Warp -> Write (BEAM-DIMAP)”
    It is during the Warp process that the above exception occurs. I have been using the NEST Toolbox (v5.1) to perform the stack creation (this seemed to give more reliable coregistration), but the same exception occurs when I use the S1TBX (v1.1.1) and the SNAP S1TBX (v2.0-beta-08).

  3. The third workflow performs the orthorectification:
    “Read Stack -> LinearTodB -> Terrain Correction -> Write (BEAM-DIMAP)”

Interestingly I find that if I do not subset the input products, then the subsequent coregistration process completes successfully. However, the processing takes 10 times longer to complete and generates larger intermediate products. As a workaround, I can then clip the output products to the required AOI.

I am not clear whether by subsetting the input products, I create an issue with the subsequent stack creation or whether there is a setting(s) that could be changed to enable the stack creation to complete successfully.

My processing environment is as follows: CentOS release 6.6 (Final) with 16GB memory.

Thanks in advance for any helpful feedback.

Kind regards,
Steven

#2

I also ran into this problem and luckily managed to determine its cause. This happens when the master and slave images are already near-perfectly aligned (that is, when the sum of the absolute differences between the master and slave images’ GCPs is less than 0.01px). In that case, the warp coefficients are directly set to their obvious values (x’=x, y’=y), but that code branch also leaves a variable that is required later in the code unset, causing this error.

I submitted a pull request with a fix here: https://github.com/senbox-org/s1tbx/pull/15

2 Likes
#3

Hi valgur,

Thank you for your message. Well done for resolving this issue and submitting a fix. I had a look at the code you highlighted and can see how this issue arises.

Empirically, I found a workaround to this issue, which is to extend the polygon in the subset operation to cover an extended region. I think this is consistent with your explanation, since by adding more ground control points to the AOI, the sum of the absolute differences between the master and slave GCP coordinates might increase above the 0.01 threshold and thus avoid the warp error.

Thanks very much for your help. Hopefully your fix will appear in a new release of SNAP/S1TBX.

Kind regards,
Steven

#4

Good work Martin. I’ve merged your pull request and will test it further.

1 Like