Ask a question

Enter questions and answers or comments here (you must be registered and logged in). All registered users are welcome to add to this page. Please subscribe to this page if you want to receive e-mail notification of new questions or answers.

How do I become a member of ROI_PAC Wiki?

1. Create your user account (register). It is strongly recommended to use FirstnameLastname (with no space between words--a WikiName) as your username.

2. Send an email to FariaChowdhury or EricFielding requesting to be added as a member. Please include some information about your interest in ROI_pac and tell us what username you have registered.

You need to do both of these steps if you want to be able to modify pages other than this question and answer page.

No, the Envisat Level 0 (raw) data files only contain one state vector, which is not sufficient for processing. You must get the orbit information from either the ESA DORIS orbit files or the Delft ODR orbits.

Yes, ROIpac was designed to process the two images at the average of the two Doppler centroids. It does the azimuth spectrum filtering (cutting out the part of the azimuth spectrum that does not overlap) in the "roi" program. It is possible to do the azimuth spectrum filtering in the interferogram formation, but this is not what "resamp_roi" does. The Delft DORIS software does the filtering in the interferogram stage, as it must because it starts with SLCs.

In addition, there is another significant difference between the way that ROIpac and other SAR processors use the Doppler centroid in the SLC formation. ROIpac is set up to process the SLC in the original geometry, but the ESA processor (and probably the Canadian Radarsat-1 processor) produce the SLC images in a deskewed geometry. The deskewing moves the data to adjust for the squint or angle between the radar LOS and perpendicular to the orbit track. Because the Radarsat-1 data has a large squint (typically about 3 degrees at middle latitudes), this is a large effect. This will make it extremely difficult if not impossible to combine ROIpac SLCs with the SLCs from the other processor.

It should be possible to make interferograms between two SLCs processed by the same system as long as the Doppler centroids are not too different. We did this with the Bam earthquake Envisat ASAR SLCs before we got the raw data. You should set the Doppler centroid to zero in the .slc.rsc file if you use ROIpac to process deskewed SLC data.

The .raw.rsc files are not really necessary if you are running the roi program without the Perl scripts. The Perl scripts read the .rsc files to create the .rdf file, and the program only reads the .rdf file and the data files. To use the rest of the ROI_pac Perl scripts, you would want to create the .slc.rsc file for the output from roi. 

i/q means (-) = 15.6555004 15.3079996 15.6555004 15.3079996 ! file 1 (i,q), file 2 (i,q)
Flip i/q? (-) = n                               !

Seasat data is offset video so obviously does not have i/q. Does roi assume IQ? If so do I have to write a program that demodulates Seasat to baseband IQ? If not, how do I tell roi that my data is offset video? Or is there a separate routine that handles non complex data.

The roi program definitely processes offset-video data. I used it many times for SIR-C data that is offset video. You just need to put "o" (for offset video) in the "Flip i/q?" answer. It will do the decoding automatically.

When you use the DOR option in make_raw_envi.pl, the script copies the Envisat DORIS orbit data from ESA (either POR orbits from $POR_DIR or VOR orbits from $VOR_DIR) to a hdr_$date.rsc file. The rest of the processing should then be done with the $orbit_type set to HDR. This was a shortcut to avoid modifying the state_vector.pl script to read the Envisat DORIS orbit files. 

//////My PALSAR Data//////
Mode     : FBS
Level    : 1.0
off-nadir angle : 34.3
Orbit Direction : Descending
PRF : 2145.923000(Same PRF)
SceneShift      : -4
//////*.PRM//////
num_rng_bins     11304
bytes_per_line   21100
good_bytes_per_line     21020
num_lines        35193
//////*.raw.rsc//////
FILE_LENGTH      35193
XMIN     413
XMAX     21020
WIDTH    21100
YMIN     0
YMAX     35193
//////*.slc.rsc//////
FILE_LENGTH      38680
XMIN     0
XMAX     10303
WIDTH    10303
YMIN     0
YMAX     40564

In ROI_pac it is normal for the YMAX of the SLC to be larger than the YMAX of the raw data. The difference is larger for PALSAR because it has a longer synthetic aperture. It is not clear why the YMAX of the SLC is larger than the FILE_LENGTH parameter. Are you using the ROI_pac v. 3.0 scripts?

To process the interferogram with no range looks (but still having azimuth looks determined by the pixel_ratio), you need to change three values to change the number of range looks: 

Rlooks_int=1
Rlooks_unw=1
Rlooks_sim=1

You can process a subset of the raw data file using a roi.proc file in the directory above the directories of the individual dates. This file is used to determine which part of the raw data to process for all of the dates. You can also put a file into the directories of the individual dates called $date.proc (whatever the name of your $date directory) with the same information. It should contain all the parameters you want to change in the processing of the raw data to SLC. For example: 

before_z_ext = -1000
after_z_ext = -12000
near_rng_ext = -0
far_rng_ext = -3950

All of the "_ext" values are "extensions" from the area of the raw data, so negative extensions mean that the SLC will be smaller than the raw data. The default values are calculated in roi_prep.pl but the .proc file values will override the defaults.

As you may know, "segmentation violation" errors can be caused by a number of things. The first thing to check is whether the 930110_roi.in file has anything strange in it. Another thing to check is the build and link to the FFTW libraries. It is strongly recommended that you use the contrib/install-fftw.sh script to build FFTW with the required single-precision code and use that. Other FFTW builds are not likely to work. If the FFTW build is bad or incompatible, then all of the programs that use them will fail.

Core file generation is controlled by your shell. Often the "coredumpsize" is set to zero in the shell, which causes no core files to be created. Under Linux csh-type shells, you can use limit core 10m to set the limit to 10 MB.

You probably need to compile the code with the debugging symbols to use gdb effectively. You can build ROI_pac with the debugging flag -g by using the gfortran-g build of contrib/multibuild.sh. Another debugging tool in Linux is strace which will print information about all the system calls made by the program. 

before_z_ext = -13900
after_z_ext = -7076
near_rng_ext = -5900
far_rng_ext = -2250

then processing with command "process_2pass.pl int.proc" gave an error like this: 

Creating 19960423.slc
+roi.pl ROI_PAC_3_0/ROI_PAC/INT_BIN/roi 19960423_roi.in > 19960423_roi.out
At line 812 of file ROI_PAC_3_0/ROI_PAC/roi/roi.F
Fortran runtime error: RECL parameter is non-positive in OPEN statement
+roi.pl roi failed in roi.pl
+raw2ampintcor.pl roi.pl failed in raw2ampintcor.pl
+process_2pass.pl raw2ampintcor.pl failed in process_2pass.pl

The important thing to note is that the WIDTH in the .raw.rsc file is in bytes and there are two bytes for every data sample. The range extension values must be specified in samples, so you probably need to divide your near_rng_ext and far_rng_ext values by two. The width of most SAR images is around 6000 samples, so the near_rng_ext and far_rng_ext values you used add to much more than the full width. Also, for ERS data, there are usually an extra 412 bytes at the beginning of each raw data line XMIN 412 and this further reduces the width of the actual data.

I have not done this myself, but I have seen another person's TerraSAR-X interferogram. If you have not used ROI_pac before, I would recommend processing the sample dataset and examining the .slc.rsc files that contain the metadata about the .slc images.

elsif ($facility eq "EODC") { $facility = "UK-PAF";} 

Keyword FIRST_FRAME_SCENE_CENTER_LINE doesn't exist in tmp_IMAGERY.raw.rsc, returning 0
Keyword FIRST_CENTER_HOUR_OF_DAY doesn't exist in tmp_IMAGERY.raw.rsc, returning 0
Keyword FIRST_CENTER_MN_OF_HOUR doesn't exist in tmp_IMAGERY.raw.rsc, returning 0
Keyword FIRST_CENTER_S_OF_MN doesn't exist in tmp_IMAGERY.raw.rsc, returning 0
Keyword FIRST_CENTER_MS_OF_S doesn't exist in tmp_IMAGERY.raw.rsc, returning 0


No good range counter found using reference counter = 4114

elsif ($facility eq "EODC") { $facility = "D-PAF";}

The first thing to try is just specifying the facility on the make_raw.pl command line. It is an optional fourth parameter. This will allow you to try the different facility types already supported without changing the Perl script. It sounds like your modifications were not working correctly.

If you are sure that none of the existing facilities will work for your data, then you need to find a reference document for the facility that processed your data. The help desk of that facility may be able to help.

I'm trying to do some InSAR using ROI_PAC with a PALSAR pair. However, I just cannot get the two SLC to register. I keep getting the classic error: 

Too few points left after culling, 2 left

I should mention that the SLCs are each made from two adjacent scenes. I used the latest make_raw_alos.pl to pre-process these, which worked without any errors and filesizes are as expected. The pair covers a coastal area, but about 2/3 of the area in the SLCs are solid ground, as is the centre of the scene. There is certainly more than enough solid ground for good registration.

I've checked the PRF (~2100) and they are very close to each other.

I also checked the DOPPLER_RANGE0 value in the both the *.raw.rsc and the values are within the correct 0.5 and -0.5 range.

I tried pixel_ratio=2 in the *.proc file, which improved things slightly. I got 198 points initially, which were then culled to just 2 again!

The obvious thing that cried out to me was a large azimuth offset caused by timing errors (as in Eric Fielding's example). I took a closer look at the SLCs and found a large (excessive?) azimuth offset of ~3170 (even more than Eric's example and maybe ~1.5 second timing error?). Therefore I used y_start=3170 in the *.proc file. However, now I don't even get the 198 initial offset points, again! I thought I might have got the sign wrong, so tried y_start=-3170, but there was no change in the result. The range offsets are negligible, but I tried adding x_start=0.01 just in case, but to no avail.

The SLCs looks sensible and well focused with no obvious problems (at least that I can see). There is some Radio frequency interference (RFI), but there seems to be plenty enough non-RFI areas to allow a good registration. I haven't seen anyone else mention RFI in PALSAR though...?

Does anyone have any other suggestions about what might be going wrong and how to fix it? 

synth_offset.pl Culling points
dem2diff.pl synth_offset.pl failed in dem2diff.pl
process_2pass.pl dem2diff.pl failed in process_2pass.pl

simrawio9

The SIM_raw.hgt file almost always has some voids in it, with the pattern depending on how the DEM spacing is mapped into the SAR image coordinates. If the DEM has a coarser spacing than the SAR data, then the voids can be a majority of the pixels. Normally, the "Aik_resample" program that is run after IntSim interpolates over these voids to produce a SIM_4rlks.hgt (or similar) file that is used in the rest of the processing.

You should compare the SIM_4lks.hgt file to the date1-date2_4rlks.cor file to see if they look similar because those are the files that are matched by "synth_offset.pl"

The Sky Telemetry Format (STF) data from ASF cannot be ingested with the programs released with ROI_pac v. 3.0. The data format is completely different, so it requires a different program to read the STF level 0 data. We hope to include the STF data reading program and associated scripts with the 3.0.1 release.

The unwrapped phase can be converted to range change by multiplying the phase (in radians) by the radar wavelength/4*pi with the length units of the wavelength.

AskQuestion (last edited 2008-11-18 00:42:36 by EricFielding)