Forums » GAMMA Processing » SAR Data Preprocessing » ALOS »
Coregistration via a lookup table (considering terrain heights)
Added by Chunli Dai over 5 years ago
Hi all,
I am trying to coregister two ALOS-1 PALSAR images (ALPSRP083631060 and ALPSRP137311060). I am following the DIFF/GEO user's guide (Geocoding and image registration). I got an error message for the step of resampling SLC to reference SLC using SLC_interp_lt (example I.8 in DIFF/GEO user's guide).
The command is: SLC_interp_lt 20080822.slc 20070820.slc.par 20080822.slc.par lt1 20070820.mli.par 20080822.mli.par - 20080822.rslc0 20080822.rslc0.par
Part of the message is:
"WARNING: no overlap with lookup table, max range: -1 max line: -1
block: 0 SLC-2R output start line: 0 SLC-2R end line : 837
LT start line: 0 LT end line: 121 lines: 122
SLC-2 data segment range sample min: 9865 max: 134 azimuth line min: 27631 max: 134
number of range pixels per block: -9730
number of azimuth lines per block: -27496
ERROR calloc_2d: memory allocation error for line pointers".
I visually check the coverage of lookup table seems to have good coverage with the reference image (see attached files). My Gamma version is kind of old (v1.6 13-Feb-2008). I am not sure whether this is a bug by the old version or I did something stupid.
Thanks for any help!
Best,
Chunli
Replies (4)
Coregistration via a lookup table (considering terrian heights) - Added by Charles Werner over 5 years ago
Hello,
Your software version is ancient.
Remember, when ever you want help with a program, please include ALL the screen
output. It is very helpful.
It appears to me that one of your files may be empty, or cannot be read. Another
possibility is that when generating the lookup table you switched the reference
and slave scenes.
This program has been changed quite a bit internally over the last 11 years, why
not get an upgrade to the current version?
We now use high order lanczos interpolation, and the lookup table values are
based on the azimuth line time instead of PRF.
Best regards,
Charles
RE: Coregistration via a lookup table (considering terrain heights) - Added by Chunli Dai over 5 years ago
Dear Charles,
Thank you very much for your prompt reply! I especially appreciate your patience despite that we are using an ancient version. We are considering upgrading the software.
Here I am attaching ALL the screen output (log.txt). I carefully examined each step again, and I don't think the order of reference and slave scenes is switched. I am attaching the steps that I processed (runexBI.sh) if it helps at all.
Yes, the size of the lookup table is the same as the reference MLI image. And I think the lookup table is generated from two MLI images.
Thanks again for your time and patience!
Best,
Chunli
log.txt (2.2 KB) log.txt | |||
runexBI.sh (2.43 KB) runexBI.sh |
RE: Coregistration via a lookup table (considering terrain heights) - Added by Charles Werner over 5 years ago
Hello,
Well if you look at the values in the lookup table you will see that the
coordinates (the lookup table are the range and azimuth coordinates in the
second image) have values that are outside the size of the input image. You can
use the program dismph to examine the values in the lookup table.
negative values, or values outside the number of slant range samples or number
of SLC image lines in azimuth would be outside the bounds of the SLC.
Are the two images from the same track?
Did you make sure that the state vectors are valid?
There probably is some systematic error
I have included a link to an example using a pair of SLC images, showing
coregistration, interferogram generation, phase unwrapping, and terrain geocoding.
This is a pair of ERS images with the Hector mine earthquake.
https://1drv.ms/u/s!Ag_xahLucCVfigjpFVOQy0fgJnRk
Certain programs are missing from your 2008 version of the software, so I can
not promise all will work with your version. But most should. First try the work
flow without geocoding and see if you can create the interferogram. If it does
not work, well, get the software update.
I have included a few scripts in the example so that you can make the
interferogram both with and without the DEM, they are in the scripts directory.
HTML documentation is in the html directory. SLC data in the slc directory. The
readme will describe the work flow.
I suggest that you try coregistering the images first without a DEM or lookup
table. Later you can get an accurate DEM and proceed from there.
In any case, if you are doing offset tracking, the current software will be a
big benefit, since we have made substantial improvements in reducing biases.
Since your version is so old, there may be issues with using the script. You
need it make an SLC_tab, using the attached script mk_tab. The SLCs to be
registered should all be in one directory.
If you are working with Sentinel data, the work flow is substantially different
since these are ScanSAR data, not stripmap. There is no support for Sentinel in
the 2008 version of Gamma. Launch was still 6 years in the future.
Best regards,
Charles
RE: Coregistration via a lookup table (considering terrain heights) - Added by Chunli Dai over 5 years ago
Dear Charles,
Thank you for your detailed instructions and for sharing your DEMO!
I just checked the lookup table values, and they look normal to me.
The two images have the same Frame and Path number. Yes, I did try the coregistration and interferogram without geocoding. The smoothed interferogram looks great with nice fringes (see attached "20070820_20080822.sub_int.SM.bmp" (steps include coregistration without geocoding, interferogram, topographic phase removal, and smoothing)).
I also tried the coregistration with geocoding using the coregistered pair of images without a lookup table, which I got the same error.
I have been struggling with these for weeks. Your help means a lot to me. I put the necessary files in https://www.dropbox.com/s/cp8flf06jlpm5e0/alosokmokcoregdem.zip?dl=0, I'd appreciate it if you could kindly try this command with your current version with these files: "SLC_interp_lt 20080822.slc 20070820.slc.par 20080822.slc.par lt1 20070820.mli.par 20080822.mli.par - 20080822.rslc0 20080822.rslc0.par". If yours works, it means the error is caused by the old version of the software.
Meanwhile, I'll go through your demo with my files to see if I get any improvement.
Thank you again so much for your time and patience!
Best,
Chunli