ERS-2 Coregistration Errors (java.lang.NullPointerException) and (java.lang.ArrayIndexOutOfBoundsException: -1)

SimoneA · March 8, 2021, 8:50pm

Dear @ABraun I’ve done this:

I tried the coregistration and once again the “-1” appeared at the end of the process. This is the error:

And these are the details:

java.lang.NullPointerException
	at org.esa.snap.core.gpf.internal.OperatorContext.isComputingImageOf(OperatorContext.java:1271)
	at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:72)
[catch] at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at javax.media.jai.PlanarImage.cobbleShort(Unknown Source)
	at javax.media.jai.PlanarImage.getData(Unknown Source)
	at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
	at org.esa.s1tbx.insar.gpf.coregistration.CreateStackOp.computeTile(CreateStackOp.java:883)
Caused: org.esa.snap.core.gpf.OperatorException
	at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
	at org.esa.s1tbx.insar.gpf.coregistration.CreateStackOp.computeTile(CreateStackOp.java:926)
	at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:82)
[catch] at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at javax.media.jai.PlanarImage.getData(Unknown Source)
	at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
	at org.esa.s1tbx.insar.gpf.coregistration.CrossCorrelationOp.computeTileStack(CrossCorrelationOp.java:492)
Caused: org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
	at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
	at org.esa.s1tbx.insar.gpf.coregistration.CrossCorrelationOp.computeTileStack(CrossCorrelationOp.java:498)
	at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:122)
[catch] at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:86)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at javax.media.jai.PlanarImage.getData(Unknown Source)
	at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
	at org.esa.s1tbx.insar.gpf.coregistration.WarpOp.getWarpData(WarpOp.java:535)
	at org.esa.s1tbx.insar.gpf.coregistration.WarpOp.computeTile(WarpOp.java:454)
Caused: org.esa.snap.core.gpf.OperatorException: java.lang.NullPointerException
	at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
	at org.esa.s1tbx.insar.gpf.coregistration.WarpOp.computeTile(WarpOp.java:500)
	at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:82)
	at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at javax.media.jai.PlanarImage.getData(Unknown Source)
	at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
[catch] at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:86)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at com.sun.media.jai.util.RequestJob.compute(Unknown Source)
	at com.sun.media.jai.util.WorkerThread.run(Unknown Source)

and

java.lang.NullPointerException
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:440)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
	at org.esa.s1tbx.insar.gpf.coregistration.WarpOp.getWarpData(WarpOp.java:535)
	at org.esa.s1tbx.insar.gpf.coregistration.WarpOp.computeTile(WarpOp.java:454)
Caused: org.esa.snap.core.gpf.OperatorException
	at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:440)
	at org.esa.s1tbx.insar.gpf.coregistration.WarpOp.computeTile(WarpOp.java:500)
	at org.esa.snap.core.gpf.internal.OperatorImage.computeRect(OperatorImage.java:82)
	at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at javax.media.jai.PlanarImage.getData(Unknown Source)
	at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeRect(OperatorImageTileStack.java:116)
[catch] at org.esa.snap.core.gpf.internal.OperatorImageTileStack.computeTile(OperatorImageTileStack.java:86)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at com.sun.media.jai.util.RequestJob.compute(Unknown Source)
	at com.sun.media.jai.util.WorkerThread.run(Unknown Source)

Do you have an idea of what these errors actually mean? I really don’t know what to try more, I tried whit all settings and still, the same errors come up

Thank you very much

#EDIT

I tried these settings and after 5-10 minutes I got this error:

java.lang.IllegalStateException: no product reader for band 'null'
	at org.esa.snap.core.image.BandOpImage.computeProductData(BandOpImage.java:65)
	at org.esa.snap.core.image.RasterDataNodeOpImage.computeRect(RasterDataNodeOpImage.java:127)
[catch] at javax.media.jai.SourcelessOpImage.computeTile(Unknown Source)
	at com.sun.media.jai.util.SunTileScheduler.scheduleTile(Unknown Source)
	at javax.media.jai.OpImage.getTile(Unknown Source)
	at javax.media.jai.PlanarImage.cobbleShort(Unknown Source)
	at javax.media.jai.PlanarImage.getData(Unknown Source)
	at com.bc.ceres.glevel.MultiLevelImage.getData(MultiLevelImage.java:64)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:449)
	at org.esa.snap.core.gpf.internal.OperatorContext.getSourceTile(OperatorContext.java:435)
	at org.esa.snap.core.gpf.Operator.getSourceTile(Operator.java:459)
	at org.esa.s1tbx.insar.gpf.coregistration.CrossCorrelationOp$2.process(CrossCorrelationOp.java:674)
	at org.esa.snap.core.util.ThreadRunnable.run(ThreadRunnable.java:23)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

This is strange… Never seen it before.

I was wondering, can coregistration be done on the 3 erroneously coregistered scenes individually and then merged? Or it must be done all in one go?

ABraun · March 9, 2021, 6:33am

You can try to run the coregistration with all images except for these three and in a second round with the same reference image and the three remaining ones. Please report if this works.

marpet · March 9, 2021, 7:43am

Maybe @lveci or @jun_lu can have a look at this?

SimoneA · March 9, 2021, 12:36pm

Dear @ABraun and @marpet, I believe I found the issue, which, however, I don’t think is fixable. So, I tried this:

But it didn’t work too. So I tried to further check all the scenes. What I have noticed is that the 3 failed scenes are completely offset compared with the others (the successful coregistered ones) (the below image shows the scenes before coregistration, only with orbit applied*):

Here is what I mean: the Master (in green) and the scenes successfully coregistered in previous tries (in yellow) are all well geolocated. As you can see, they graphically match the extent of the Master. On the other hand, the scenes that failed (7, 13 and 18 - in red), are completely offset compared to the Master’s extent, and I believe this is what caused them to fail, regardless of the numerous coregistration settings and approaches I have tried.

Now, assuming that these scenes (7, 13 and 18) are completely offset, is there a chance to re-align/re-georeference/adjust them somehow? Or they are just lost?

Thank you very much for your help.

Regards,

Simone

*I checked the scenes before applying the orbits and nothing changes, they are still offset.

ABraun · March 9, 2021, 12:45pm

this would indeed explain why these three fail to match the others.
Are their footprints in the WorldView tab shifted as well?
But they all belong to the same track, right?

SimoneA · March 9, 2021, 12:50pm

Thanks for your reply @ABraun , they all belong to the same track and in the world view, the footprints look all aligned! Any idea?

ABraun · March 9, 2021, 12:57pm

this means that the metadata on geolocation does not match the captured area.

Usually, the DEM-assisted coregistration can handle this, but the offset might be too large to fall inside the registration tolerance.

What happens when you apply a spatial subset on all images based on geographic coordinates?
You can define the WKT here and use it in the subset tool as described here. Afterwards, all products should have the same extent. This can lead to several outcomes

all products now have the same extent and the three faulty ones cover the correct area
the subset of the three faulty ones is shifted as well - then the geolocation information is incorrect in general

SimoneA · March 9, 2021, 1:29pm

Thanks, @ABraun. I tried this previously:

And even after subsetting before the coregistration, didn’t solve the problem.
These are the subsetted (orbit applied) Intensities (before coregistration):

7, 13 and 18 remain offset even after subsetting defining WKT.

So should I assume they are badly georeferenced?

Out of curiosity, how is it possible that the footprint is displayed correctly? Does it use a different set of coordinates?

Also, are there any other approaches that might solve the issue, or there is nothing to do at all?

Thanks a lot!

ABraun · March 9, 2021, 1:34pm

I’m afraid so, yes. If the same coordinates are located at different parts of the images, the images’ geocoding is not correct. You might contact the EO Help to ask if they can re-process the images. https://esatellus.service-now.com/csp/
List them the image IDs and a screenshot of the footprints along with screenshot of both correct and shifted images, so they understand that the three you mention do not cover the area which is given in the metadata.

The footprints are probably just computed based on coordinate information within the metadata, but the coordinates of the image have an offset. Apparently, these coordinates are not correct.

SimoneA · March 9, 2021, 1:39pm

@ABraun Thanks a lot for your help throughout the entire process, I really appreciate that. I just got one question left. As the coregistration performed before has been successful for the other scenes, how can I remove only the faulty ones and proceed with the interferograms formation? Is there any specific way to do that to avoid future errors in the coming steps?

Thanks a lot once again.

Simone

mengdahl · March 9, 2021, 2:05pm

Hmm, isn’t there an “initial offset” - setting that would tell the co-registration module from where to start the seach, in case of huge displacements? (I remember having requested for that years ago)

ABraun · March 9, 2021, 2:24pm

you can create a band subset based on the entire stack and un-check all faulty dates. This will ensure correct handling of metadata.

I am not aware of such an option which allows to define an initial shift for individual images.

@SimoneA How large (in pixels) is the offset? The automated estimation of initial offsets offers windows of up to 2048 pixels width.

One last thing to try: Apply the orbit file and then range-doppler terrain correction using “complex output” and “nearest neighbor” resampling of the data. If the data is projected correctly, you can use the terrain corrected products as input for the coregistration and select “Product Geolocation” instead of “Orbit” as Initial Offset Method. Maybe this tricks SNAP into correctly overlaying the input data, although there might be new issues because the data are no longer in slant geometry. But worth a try.

mengdahl · March 9, 2021, 2:30pm

I think we should add initial offset setting into the co-reigistration as simply widening the search window is tremendously wasteful especially on images with normal locational accuracy.

SimoneA · March 9, 2021, 3:59pm

Dear @ABraun and @mengdahl, thank you both for your advice.

I will try them both and post the outcome soon (hopefully it won’t take 13 hours).

@ABraun Could you kindly tell me where to find this information, please?

@mengdahl regarding the initial offset, all I can see is either Orbit or Geolocation, is it this supposed to be somewhere else?

I wondered how I could do this:

I could try change the settings in the cross-correlation tab > Estimate Initial Coarse Offset, if that can be the one, but which are the settings to adjust?

mengdahl · March 9, 2021, 4:59pm

If you only take the images that can be used for PS-InSAR (compatible Doppler, baseline clearly under critical baseline length), you are left with a much reduced stack that is faster to co-register.

SimoneA · March 9, 2021, 5:05pm

The problem is that already some scenes are missing for that period and ROI, therefore, I really need to maximise the available scenes.

mengdahl · March 9, 2021, 5:15pm

Unfortunately it is impossible to do InSAR with images that are not InSAR-compatible, even if co-registration works. With respect to your chosen master-scene the following images are fully or almost fully incompatible:

Due to Doppler-centroid difference: 1,3,4,5,10,11,15,18,23
Due to too large perpendicular baseline: 13,17
Image 19 is a borderline case for both.

ERS-2 suffered from loss of gyroscopes which worsened both orbit (baseline) and pointing (Doppler-centroid) control since 2000, see: Review of the Impact of ERS-2 Piloting Modes on the SAR Doppler Stability

If that is the timeframe and area you are interested in I would recommend you to download Envisat ASAR data that does not suffer from those same issues.

See this reference for more info: InSAR Principles: Guidelines for SAR Interferometry Processing and Interpretation (ESA TM-19)

SimoneA · March 9, 2021, 5:23pm

Thanks a lot @mengdahl I really appreciate your help. I will very much consider Envisat instead, and see if my life will get easier. Will keep you posted, thank you so much!

ABraun · March 12, 2021, 2:45pm

we discussed this again and wanted to suggest the following things to try (maybe for a test only with one correct and one faulty product):

apply the “Update Georeference” operator (Radar > Geometric) to one of the faulty products and see if the result is more suitable for coregistration
increase the coarse registration window size as large as possible
compare DELFT and PRARE orbits to check if one of them produces better coregistration results

Please test only one of these options at a time to see if the change has an impact. We are interested in your experience, once you can share something (both good or bad)

SimoneA · March 12, 2021, 3:07pm

Dear @ABraun thank you to further investigate my issue. I currently changed to Envisat, and I completed the whole STaMPS process without significant issues. However, as soon as I’ll get a minute, I will try these steps and I will post the results, hopefully within the next week!