Achieving accurate registration of ALOS-PALSAR data to compare with Sentinel-1

Microwave Toolbox
#1

Hi there, I’m trying to acquire sigma0 SAR images at L-band or other wavelengths which I can compare to the sigma0 values from Sentinel-1 C-band images of my study sites. The ASF provides their HyP3 on-demand processing of Sentinel-1 images that results in great registration, but I’m having difficulty getting other datasets to precisely align with this Sentinel-1 data. I’ve tried several different routes to get ALOS-PALSAR data that would work, but to no avail. Please let me know if there’s a possible solution to any of the issues I’ve encountered below, or perhaps a completely different approach I should be trying.

  1. Converting gamma0 to sigma0: ASF has put out RTC data for ALOS-PALSAR that has great registration with the HyP3 Sentinel-1 images. However, since these PALSAR images are calibrated as gamma0 instead of sigma0, I’m wondering how to convert from gamma0 to sigma0 using SNAP? Would it be as simple as using Band Maths with the gamma0 image and the associated incidence angle map from ASF?

  2. Processing PALSAR L1.1 data in SNAP: Going through the steps of calibration, multilook, deskewing, and then SAR Simulation Terrain Correction (as described here), I can’t get the registration as good as the ASF RTC gamma0 products (offset by >10 pixels). The result from Range-Doppler Terrain Correction is even worse at my study sites. I’ve tried changing the number of GCPs, RMS threshold, and coarse window widths with no obvious improvement. I’ve tried the SRTM 3Sec and Copernicus 30 m DEMs. Is there anything else I should try to improve the result?

  3. Processing PALSAR L1.5 data in MapReady: Maybe not the right forum for this, but if I try to do radiometric calibration and then terrain correction, the software crashes when I try opening the calibrated file. If I try to do radiometric calibration as part of the terrain correction process (following from page 6 here) I’m told the DEMs I’ve selected don’t contain tie points (e.g., the ASTER GDEM V3, as suggested here) and MapReady also crashes if I try to load in DEMs to create a mosaic.

  4. Co-registration of PALSAR data in SNAP: If I try to use GeFolki co-registration on my SNAP-processed L1.1 data with the ASF PALSAR RT1 data as master, the software seems to freeze. Trying to use DEM Assisted Coregistration, I get the error that Metadata radar_frequency has not been set – I’m guessing this has to do with using the ASF RT1 GeoTIFF as a master(?). Using the standard Coregistration tool seems to produce a nice result, but for some reason changes the histogram of sigma0 values. I expect this is due to resampling but the new minimum value is negative (e.g., -0.6) instead of 0. What is causing that change and should it be of concern?

I’m also open to exploring other datasets if I can reliably get the image product to be registered within <1 pixel or so for comparison to Sentinel-1. I’m feeling a bit lost at this point so thanks in advance if you can clear up any misunderstandings or make any suggestions.

#2

Could it be because of bilinear resampling of the coregistered image? You can try Nearest Neighbor resampling instead and compare. The standard coregistration would have been my first choice as well.

#3

Thanks for the suggestion. I’m not sure I understand from the SNAP Help documentation what the difference is between the resampling of the CreateStack tab and the interpolation of the Warp tab. Is the first just regridding to match the master resolution and the second is actually co-registering the image?

If I select Nearest Neighbor resampling under CreateStack and also under Warp instead of the default Cubic Convolution interpolation, I get values like I would expect. Can the weighting used in bilinear and cubic interpolations result in negative values?

#4

Resampling defines how pixels are recalculated in case of rotation and shifts, while interpolation defines how the new locations of all identified matching GCPs are mathematically converted into a transformation for the entire image.

So in my opinion the first was responsible for the negative values because of local convolution.

#5

Having tried a few different variations, it seems like setting the warp interpolation to bilinear or the cubic convolution default is producing the negative values. Is it possible to perform each step of the coregistration individually to see them more closely?

I’m not sure how the transformation produces negatives, but perhaps it is only a problem at the extremities of the histogram and not so much an issue for my study areas. If I instead use nearest neighbor, then I get some duplicate neighboring pixels (see below), which seems like a potentially greater issue.
duplicate_pixels

#6

How could either of the coregistration steps produce negative values from an input that is entirely positive?