PROCESS VALIDATION - Terrafirma.eu.com

Remote Sensing Technology Institute Terrafirma Stage II - Process Validation -

Doc.: VAL Issue: 1.8 Date: 13.04.2007 Page: 1 of 62

Terrafirma SPECIFICATION OF VALIDATION APPROACH PART 1: PROCESS VALIDATION DLR-IMF – Remote Sensing Technology Institute

prepared: N. Adam / A. Parizzi

Date

approved: M. Crosetto

Date

released: Ph. Bally

Date



DOCUMENT CHANGE CONTROL // // // // // // // // // // // // // // //

************************************************************* Project : Terrafirma Stage II CVS logging terrafirma validation list of deliverables ------------------------------------------------------------File : $RCSfile: terrafirma_validation_delivarables__cvs.doc,v $ ------------------------------------------------------------Version : $Revision: 1.8 $ ------------------------------------------------------------Date : $Date: 2007/05/31 13:31:16 $ ------------------------------------------------------------Author : Nico Adam ------------------------------------------------------------Last modified by: $Author: nadam $ *************************************************************

/* ************************************************************* * $Log: terrafirma_validation_delivarables__cvs.doc,v $ * Revision 1.8 2007/05/31 13:31:16 nadam * - clarified the start of coordinate system: it is now related * only to the cropped area not the total (master) scene (p.27) * * Revision 1.7 2007/05/29 18:52:55 nadam * - added request for description of all modelled parameters * (audit); * - added deliverable of used Doppler frequency for the processing; * - added check for offset in absolute estimates due to different * ref. points; * - added hint on scaling of short integer complex SLC data and * allowed float complex data; * * Revision 1.6 2007/05/29 15:32:03 nadam * - removed fix number for data amount (p. 10); * - clarified parameters: max number of network points and number * of reference points (p.18); * - added const. DEM value of 43.0 m related to WGS84 ellipsoid (p.16) * * Revision 1.5 2007/05/04 15:32:57 nadam * - finished overview on deliverable files; * - updated audit for OSPs reference PS(s); * - answered comments from IG; * - added source code for the extended SRF; * * Revision 1.4 2007/04/13 07:22:25 nadam * - added missing data: displacement time series and outlier mask; * - added section on processing data selection; * - fixed coherence estimation equation typing error; * * Revision 1.3 2007/04/05 12:13:22 nadam * - finished preview version of the document * * Revision 1.2 2007/03/19 09:52:55 nadam * - document setup and structuring of basis * * Revision 1.1.1.1 2007/03/19 09:24:50 nadam * - initial import into cvs * ************************************************************* */



TABLE OF CONTENTS 1

INTRODUCTION.............................................................................................................................. 5 1.1 PURPOSE AND SCOPE .................................................................................................................5 1.2 INTENDED READERSHIP ...............................................................................................................6 1.3 GLOSSARY ..................................................................................................................................7 1.4 REFERENCES ..............................................................................................................................8 1.4.1 APPLICABLE DOCUMENTS .....................................................................................................8 1.4.2 REFERENCE DOCUMENTS .....................................................................................................8 1.5 USED TEXT STYLES .....................................................................................................................8

2

PROCESS ANALYSIS OVERVIEW...................................................................................................... 9

3

SELECTED DATA FOR THE VALIDATION.......................................................................................... 11

4

PARAMETER MATRIX .................................................................................................................... 17

5

DELIVERABLES FILE FORMAT ....................................................................................................... 20

6

DATA DELIVERABLES ................................................................................................................... 23 6.1 AUDIT .......................................................................................................................................23 6.2 DELIVERABLE INTERMEDIATE DATA .............................................................................................24 6.3 ORBITS_MSB.RAS.......................................................................................................................24 6.4 T_MSB.RAS................................................................................................................................25 6.5 INTERFEROGRAMS_MSB.RAS ......................................................................................................25 6.6 DT_MSB.RAS .............................................................................................................................26 6.7 PS_X_MSB.RAS AND PSY_MSB.RAS .............................................................................................27 6.8 PHI_MSB.RAS, B_MSB.RAS, APS_IFGRM_MSB.RAS AND RESIDUAL_MSB.RAS ..................................30 6.9 AMPL_MSB.RAS, SCR_MSB.RAS, APS_SLC_MSB.RAS, TIME_SERIES_MSB.RAS AND TIME_SERIES_MASK_MSB.RAS ..............................................................................................................31 6.10 GRAPH_MSB.RAS .......................................................................................................................33 6.11 COH_REL_MSB.RAS, V_REL_MSB.RAS AND H_REL_MSB.RAS .........................................................34 6.12 COH_ABS_MSB.RAS, V_ABS_MSB.RAS AND H_ABS_MSB.RAS ........................................................35 6.13 IMAGE LAYERS ..........................................................................................................................36 6.13.1 AMPL_MEAN_MSB.RAS .....................................................................................................36 6.13.2 SCR_MSB.RAS .................................................................................................................37 6.13.3 SLC_MASTER_MSB.RAS, SLC_MASTER_OVS2_MSB.RAS AND SLC_DDDDD_MSB.RAS ............37 6.14 OVERVIEW ON DELIVERABLE FILES .............................................................................................37

7

PROCESS ANALYSIS .................................................................................................................... 40 7.1 CHECK OF DATA DELIVERY.........................................................................................................41 7.2 OBSERVATION PARAMETER CHECK ............................................................................................41 7.3 MASTER SLC PROCESSING CHECK ............................................................................................42 7.4 OVERSAMPLING AND COORDINATES TEST...................................................................................42 7.5 COREGISTRATION ACCURACY ....................................................................................................42 7.5.1 RELATIVE COREGISTRATION DEVIATION FROM MEAN MAP ....................................................42 7.5.2 RELATIVE COREGISTRATION DEVIATION FROM PS-LOCATION FILES.......................................43 7.6 RELATIVE INTERFEROMETRIC PHASE DEVIATIONS ........................................................................43 7.7 APS AND ORBIT TRENDS ...........................................................................................................43 7.7.1 DOMINANT INTERFEROMETRIC PHASE CONTRIBUTION ..........................................................43 7.8 SCENE CALIBRATION .................................................................................................................44



7.8.1 SCENE CALIBRATION COMPARED TO DLR ............................................................................44 7.8.2 SCENE CALIBRATION OSPS COMPARED TO EACH OTHER .....................................................44 7.9 PS DETECTION ..........................................................................................................................44 7.9.1 PS DENSITY COMPARED TO EACH OTHER............................................................................44 7.9.2 SPATIAL PS DISTRIBUTION COMPARED TO EACH OTHER.......................................................45 7.9.3 PS DENSITY HISTOGRAM COMPARED TO EACH OTHER .........................................................45 7.9.4 PS MISDETECTION CHECK ..................................................................................................45 7.9.5 RELATIVE PS-LOCATION DEVIATION FROM SCATTERER LOCATION FILES ...............................46 7.10 DEM AND DISPLACEMENT UPDATE TEST ....................................................................................46 7.10.1 NETWORK ASSESSMENT ..................................................................................................46 7.10.2 RELATIVE DEM UPDATE CONSISTENCY ............................................................................46 7.10.3 RELATIVE MEAN VELOCITY CONSISTENCY .........................................................................47 7.10.4 RELATIVE DEM UPDATE DEVIATIONS BETWEEN OSPS ......................................................47 7.10.5 RELATIVE MEAN VELOCITY DEVIATIONS BETWEEN OSPS ..................................................47 7.10.6 RELATIVE COHERENCE COMPARISON ...............................................................................48 7.10.7 RELATIVE APS AND RESIDUAL PHASE COMPARISON .........................................................48 7.10.8 ABSOLUTE APS PHASE COMPARISON ..............................................................................48 7.10.9 ABSOLUTE VELOCITY COMPARISON ..................................................................................48 7.10.10 ABSOLUTE DEM UPDATE COMPARISON ...........................................................................49 7.10.11 ABSOLUTE COHERENCE COMPARISON .............................................................................49 7.10.12 COMPARISON OF TIME SERIES OF SELECTED POINTS ........................................................49 7.10.13 ABSOLUTE DISPLACEMENT DETECTION COMPARISON .......................................................50 APPENDIX .......................................................................................................................................... 51 7.11 WRITE ROUTINES ......................................................................................................................51 7.11.1 WRITE_BYTE ....................................................................................................................51 7.11.2 WRITE_INT16...................................................................................................................52 7.11.3 WRITE_INT32...................................................................................................................52 7.11.4 WRITE_FLT ......................................................................................................................53 7.11.5 WRITE_DBL ......................................................................................................................54 7.11.6 WRITE_SCPLX ..................................................................................................................55 7.11.7 WRITE_FCPLX ..................................................................................................................56 7.11.8 WRITE_DCPLX ..................................................................................................................56 7.12 READ ROUTINES ........................................................................................................................57 7.12.1 READ_BYTE .....................................................................................................................57 7.12.2 READ_INT16 ....................................................................................................................58 7.12.3 READ_INT32 ....................................................................................................................59 7.12.4 READ_FLT........................................................................................................................59 7.12.5 READ_DBL .......................................................................................................................60 7.12.6 READ_SCPLX ...................................................................................................................60 7.12.7 READ_FCPLX ...................................................................................................................61 7.12.8 READ_DCPLX ...................................................................................................................61



1 INTRODUCTION The document in hand describes the Process Validation of the different persistent scatterer processing systems in the framework of the Terrafirma project. The PSI processing is an innovative remote sensing technology which allows to monitor displacements on the Earth’s surface. Companies, universities and research establishments have developed several of such processing systems and these are operationally working today. Their application projects proved the service capability and showed an astonishing accuracy of the displacement monitoring. The exciting accuracy of the single measurements is in contrast to the deviations between the processing systems output if compared among each other. These deviations have been revealed during the PSIC4 project in the course of a geo-validation. The deviations in the processing outputs of the PSIC4 project should not be misinterpreted as deficiencies in the PSI technique. The variations in PS density, PS localisation and the estimates of APS, height update and displacement are mainly caused by the different interpretations of the project’s tasks resulting in assumptions on the data which showed finally to be unsuitable for the difficult test site. I.e. on the PSIC4 test site, the generation of few simple differential interferograms provided a very good solution to this particular monitoring problem because the subsidence took place in a very short time interval. This is the reason that over 80% of the motion could be covered by interferometric pairs which span a time range of only few months allowing coherence even on distributed scatterers. Of course, this result is not based on permanent scatterers but suggests a very high PS-density. Some teams may have delivered such a result which is in contrast to the suggested PSI processing. Nevertheless the PSIC4 validation was valuable work. The solved interpolation problems to cope with the different samplings in space and time of the geo-validation data and even of the PSI processing results among each other show the expertise and high grade work of the validation group. A misconception seemed to be that the teams followed two different concepts. On the one hand some teams solved the monitoring task best (including manual tuning and lots of expertise) and on the other hand some teams demonstrated a regular standard processing of their PSI systems. Consequently the generated outputs are hard to compare. According to the status at phase 2 kick-off the PSI validation is key to Terrafirma’s future in being able to offer reliable services. The project’s ongoing validation is improved and is therefore split into two parts i.e. a Process Validation and a Product Validation. Both are defined beforehand and published.

1.1 PURPOSE AND SCOPE The Process Analysis is a different concept compared to the Product Validation and is based on intermediate processing outputs. It allows to significantly reduce the complexity of the validation without losing significance. The Terrafirma process validation is defined and performed by DLR who has developed its own independent scientific persistent scatterer processing system. An objective validation is assured because DLR has no commercial interest. This document describes the scope of the process validation work i.e. the planned process analysis of the actually existing Terrafirma OSPs processing chains. It is intended as a basis for brief technical discussions between the Terrafirma partners because cooperation and agreement between the OSPs and DLR is required. It is essential to find a balance between the disclosure of technology owned be the commercial companies and the ability to interpret and check their algorithms. The validation’s subject is



•

to determine the PSI accuracies and reliabilities in given circumstances,

•

to prove the validity of different PSI processing concepts,

•

to gain confidence of end users for the PSI monitoring and

•

to test and provide future processing protocols.

This document provides the detailed information on •

the definition of the deliverables, i.e. the intermediate products which are assessed,

•

the file format of the deliverables,

•

the definition of the units of the data values and

•

the definition of the coordinate systems,

•

the data layout and on

•

the planned process analysis using the delivered data.

1.2 INTENDED READERSHIP Operational Service Providers (OSPs) are mainly the intended readership. Both, their software developers of the interferometric systems and their operators are addressed. In the current project stage 2 of Terrafirma the actual OSPs i.e. the commercial companies Tele-Rilevamento Europa (TRE), Gamma Remote Sensing AG, Altamira Information (AI) and Nigel Press Associates (NPA) and the Institute of Geomatics Spain (IG) and the Remote Sensing Technology Institute (IMF) of the German Aerospace Center (DLR) contribute to the process validation of the PSI processing. In a later project stage new service provider can be validated on the basis of this document and the experience gained in the course of the validation.



1.3 GLOSSARY The document uses acronyms which are often used in the InSAR, PSI, Terrafirma and GMES framework. The following table lists the abbreviations: AI AIO APS CR CVS DEM D-InSAR DLR ERS ESA FFT GCP Geo TIFF GMES GRS IG IMF InSAR LOS LSB MPEG MSB NPA OSP PCC pdf PSI PTA QC QCP SAR SCR SLA SLC SNR TF tiff / tif TRE

Altamira Information area of interest atmospheric phase screen corner reflector Concurrent Versions System digital elevation model Differential SAR Interferometry German Aerospace Center European Remote Sensing Satellite European Space Agency Fast Fourier Transform ground control point tif data with added geo-information Global Monitoring for Environment and Security Gamma Remote Sensing AG Institute of Geomatics Spain Remote Sensing Technology Institute SAR Interferometry line of sight Least Significant Byte Motion Pictures Experts Group Most Significant Byte Nigel Press Associates Operational Service Provider Parametric Cubic Convolution probability density function Persistent Scatterer Interferometry Point Target Analysis Quality Control Quality control Protocol Synthetic Aperture Radar Signal To Clutter Ratio Service Level Agreement Single Look Complex Product signal To Noise Ratio Terrafirma Taged image File Format Tele-Rilevamento Europa



1.4 REFERENCES This section lists the applicable and reference documents. They should be available to understand and complete this document. 1.4.1

APPLICABLE DOCUMENTS

[A1] Statement of work TS-SW-ESA-SY-0005 July, 2004 [A2] Proposal for the study July, 2004 [A3] Proposal for the validation of existing processing chains in Terrafirma stage 2 R. Capes, R. Burren, D. Morten, C. Bremmer and J. Hoffmann, November, 2006 [A4] Technical note on the test site selection: Alkmaar-Amsterdam M. Crosetto, M. Agudo (IG), C. Bremmer (TNO), R. Hanssen (TU Delft) April, 2007 [A5] General rules to run the validation project M. Crosetto, M. Agudo March, 2007 1.4.2

REFERENCE DOCUMENTS

[R1] S5: Service Portfolio Specifications (Version 4) R. Capes and R. Burren (NPA) 21st June 2006

1.5 USED TEXT STYLES Different kinds of information are formatted accordingly in order to support the reader. The following table lists the used text styles: xv –crop 10 20 100 50 img

command line statements and file names

Developer and User Guide

document names

vec = FindGen( 3 );

source code statement or configuration text

This document ..

describing information



2 PROCESS ANALYSIS OVERVIEW Subject of the process analysis is a comparison of intermediate processing results in radar slant range geometry. This assessment is complementary to the geo-validation which is a comparison of the final processing results against independent ground-truth measurements. The geovalidation has to cope with a superposition of all effects caused by processing errors and algorithmic limitations. Nevertheless the geo-validation is an essential part of the Terrafirma validation [A3] because it shows the agreement between the measurements and the actually monitored effect. It really describes the expectation of the geo-users on the PSI processing output. In contrast the process analysis verifies the expectation of the software and algorithms developers. The main advantages of the slant range assessments of intermediate data are that

deviations in the processing output can be detected in a very early stage of the processing,

their significance can be estimated because

their propagation into the final results can be tracked and

complicated and error-prone interpolations in time and space can be avoided.

Different intermediate slant range outputs can result from the various processing systems due to

the different implemented PSI techniques,

different algorithms e.g. for the coregistration with varying robustness and accuracy,

unlike assumptions on the data and the observed signal (e.g. the non-linearity of the displacement model in time, the impact of the APS on the estimate) and

different parameters for the tuning of the actual processing to solve the particular monitoring task.

All these causes are tried to be revealed. Different parts of the process analysis definition are introduced for this reason. A survey similar to an audit provides information on the different implemented PSI techniques and partial algorithms. It is detailed by a table of parameters which are used by the operator for the actual processing. Both are needed to correctly interpret and compare the delivered data. The OSPs can rely on an individual protection of the assessment. The individual results of the processing and the audit answers are always anonymous. No characteristics, shortcomings or limitations will be reported. The basis for the comparison of the process analysis data are

a known methodology and open rules for the comparison of the data,

a detailed description of the deliverables,

a simple and practical data format for the deliverables,

the restriction to one and the same processing area,

a fix coordinate system which can cope with the different processing variants (oversampling factors and phase extraction principles e.g. PTA),

a previously defined (super) master scene.

A problem for the process validation is the amount of data which needs to be transferred from the OSPs to DLR. On the one hand the number of available data samples needs to allow a significant statistic. Furthermore, there is a need for various intermediate data in order to detect



deviations and to track the error propagation. But on the other hand the amount of data needs to be restricted to reduce logistical effort and to reduce complexity. In order to avoid overhead and sources of misinterpretation the amount of data is limited. This is achieved by a flexible data deliverable format which can be applied to all PSI processing systems. The data are delivered in binary format. This reduces the amount of data by a factor of two compared to ASCII but enables a sufficient sampling in space and time to get the maximum information out of the deliverables. The data formatting is done by the OSPs because they can handle their data themselves best and no external errors can be introduced. They are supported by a reference implementation of routines to read and write the image data in IDL (provided by e-mail and in the appendix).



3 SELECTED DATA FOR THE VALIDATION This section describes the data selection for the validation and contributes to the general rules of the validation which is compiled in the TN [A5]. The test site will be the area around Alkmaar and Amsterdam and is described in the TN [A4]. The descending orbit data stack with track 423 and frame 2542 is foreseen for the processing. At DLR, an ad-hoc quicklook PSI processing of the test site with internally available data has been performed in order to get some idea on the test site’s characteristics. DLR processed the ascending data stack (track=301, frame1053) - the data of track 423 frame 2542 were ad-hoc internally not available. Due to the limited time the processing was restricted to the city area and the Alkmaar region separately. Unfortunately, internally only 30 scenes were available which are not enough to really characterize the test site and to define the validation in more detail. But the preview processing revealed that the data acquired after January 2001 should be excluded from the validation. Fig. 1 presents two typical examples for phase time series. The red line marks the January 2001 and indicates a clear change of phase stability. Certainly these can be used in PSI processings but are known to require immense operator interaction and quality control. Such kind of processing – with questionable results - is not considered part of the planned validation.

Fig. 1: Typical examples for phase time series of the ad-hoc processed data by DLR. The red line marks the January 2001. At the moment, the data selection of the proposed stack is based on the information which is available from the DescW software and the personal communication with Freek van Leijen (TUDelft). The tasks of the OSPs for the PSI processing are: detection and measurement of the land deformation of Alkmaar and all other so far unknown deformation phenomena in the covered area. The technical note on page 4 of TN [A4] suggests that the validation group can support the OSPs and is allowed to fix the displacement model to be linear only. This means all OSPs use the same linear model for the estimation. Non-linear motion components can be estimated from the residual phase. A confirmation by those teams who have already processed this test site is appreciated. The validation should be restricted to a typical PSI processing. This is the reason no cross-interferometry should be applied. Only the sensors ERS-1 and ERS-2 are used due to the sufficient amount of available data. Fig. 2 visualizes all available ERS-1 and ERS-2 acquisitions in a time- baseline- diagram.



The non-linear deformation phenomenon in the area of the N-S line in Amsterdam should not be included into this validation. The TN [A4] on page 10 shows that this non-linear deformation occurs in September 2002. I.e. this event is during the zero gyro mode of ERS-2. The separation of the non-linear motion and the APS is still a difficult task. Every “difficult” scene at the end of 2002 can cause significant deviations in the final estimates of the OSPs. This is in contrast to the projects intention. The validation data are restricted to scenes with moderate Doppler frequencies. ESA provides the Doppler frequency evolution over time for the sensor ERS-2. Fig. 3 visualizes the different operation modes of the ERS-2 and the corresponding Doppler frequencies for the used data stack (track 423 and frame 2542). It becomes clear that the Doppler frequencies of the single acquisitions need to be checked before the processing. Fig. 4 provides an overview in the time- baseline- diagram on the scenes with known Doppler frequency values which are highlighted in blue. Fig. 5 presents the scenes in the time- baseline diagram having a moderate Doppler frequency. The red colour indicates acquisitions with a Doppler frequency in the range of +/-600 Hz. The black colour shows the scenes with an unknown Doppler frequency. Over 90 scenes are available if the data are restricted to the time before the extended backup mode (EBM) of ERS-2. This amount of data allows a robust estimation of the displacement and the DEM update. This has been checked by a periodogram which is presented in Fig. 6. It proves the suitability of the distribution in time and baseline of the selected data for the estimation of the displacement and the DEM update. An unsuitable distribution in time and baseline could be recognised by significant sidelobes making the peak detection ambiguous (i.e. risky for misdetections). Such sidelobes result e.g. from large data gaps in time or baseline. Fig. 7 shows another periodogram. It is generated from data with an effective phase noise of 30 degree. In the previous figure the peak has a height of one. Now the peak is reduced to 0.86 but can still be detected without risk. This robustness is available for all implemented algorithms because they are all in principle frequency estimators.

Fig. 2: Time- baseline- diagram of all available ERS-1 and ERS-2 data. Each black dot corresponds to a single acquisition. The red line indicates the start of the Extended Backup Mode of the ERS-2 sensor



Fig. 3: Doppler frequency over time for the test sites data provided by ESA. The different operation modes of the sensor are described in red colour.

Fig. 4: Time- baseline- diagram of all available ERS-1 and ERS-2 data. The blue colour indicates scenes with known Doppler frequency values.



. Fig. 5: Overview on the scenes with a moderate Doppler frequency. The red colour indicates acquisitions with a Doppler frequency in the range of +/-600 Hz. The black colour shows the scenes with an unknown Doppler frequency.

Fig. 6: Periodogram which checks the suitability of the distribution of the selected acquisitions in the time- baseline- diagram for the estimation of the displacement and the DEM update. An unsuitable distribution in time and baseline could be recognised by significant sidelobes making the peak detection ambiguous. Such sidelobes result from large data gaps in time or baseline.



Fig. 7: Periodogram generated from data with an effective phase noise of 30 degree. In the previous figure the peak has a height of one. Now the peak is reduced to 0.86 but can still be detected without risk.

Fig. 8: DEM visualisation of the validation test site. The mean height related to the WGS84 ellipsoid is in the order of 40m. No significant topography is visible allowing to process the data related to a constant mean height.



The PSI processing takes advantage from a compensation for the topography. It is provided by external DEMs. In order to avoid difficult and error prone coordinate conversions and complicated interfaces a simple DEM is used in the validation. Fig. 8 presents the DEM visualisation of the validation test site. The mean height related to the WGS84 ellipsoid is in the order of 40 m. No significant topography is visible allowing to process the data related to a constant mean height. Now it has been confirmed that the mean height is 43 m above the WGS84 ellipsoid for both test site areas. Only this single height will be reported to the validation teams, i.e. no DEM will be delivered and the validation teams need to estimate the height update and the absolute height related to the DEM with 43 m constant height above the WGS84 elliposid.



4 PARAMETER MATRIX The PSI processing can be adapted by the operator according to the actual monitoring task and test site. For the process analysis a description of these parameters is required. The processing system operators are asked to provide information on the parameter setting decisions and their effects on the final monitoring result. Some parameters for the PSI processing are collected in the following table. The parameter listing is redundant. I.e. some parameters are closely related to each other or describe one and the same effect. In this case, the parameter closest to the used in the actual processing system should be provided. Some listed parameters can happen to be not applicable for one particular processing system. In such a case not applicable can be written into the table. This parameter matrix is a proposal. According to WP VAL.03 it will be completed and agreed with the input of NPA, TRE, GRS and AI. Processing step InSAR processing

Parameter

Description

maximum processed Doppler frequency difference

− Distributed scatterers can not be interferometrically monitored in case the Doppler centroid frequency difference results in non-overlapping azimuth object spectra

unit: Hz

− Coregistration can become difficult for high Doppler frequency differences due to changing speckle pattern maximum processed baseline unit: m

− Distributed scatterers can not be interferometrically monitored in case the effective baseline results in non-overlapping range object spectra (critical baseline) − Coregistration can become difficult for large baselines due to changing speckle pattern

maximum processed time difference unit: days

− Distributed scatterers can not be interferometrically monitored in case the coherence (i.e. the phase relation) is lost − Coregistration can become difficult for large temporal time spans due to temporal decorrelation

minimum coherence unit: 0.0 .. 1.0 PS detection

maximum expected phase noise standard deviation unit: rad

− Distributed scatterers can not be interferometrically monitored in case the coherence (i.e. the phase relation) is lost − Persistent scatterers can be characterized by the expected phase stability over time i.e. their expected phase noise standard deviation


minimum SCR unit: digital number (power ratio)

− The expected phase noise standard deviation is a function of the SCR. This value is equivalent to the previous parameter ( ϕ eff =

minimum PS density 2

unit: number of PS / km

max / mean / min PS distance of (ref.) network unit: m

intensity threshold unit: power unit (e.g. dB, please specify) estimation network

redundancy of network unit: digital number (please specify) min / mean / max number of incidences (i.e. relative estimates) per PS unit: digital number (count) maximum number of relative estimates unit: digital number (count) maximum number of network points unit: digital number (count) used number of (reference) points


1 ). 2 ⋅ SCR

− In order to estimate the APS a good spatial distribution of the PS is required. In case the processing system adapts the SCR threshold depending on the PS density this parameter can be provided. − The APS impact on the estimation needs to be reduced. Therefore a relative estimation between nearby points is performed. The distance between these points in the final network or the reference network of estimates can be a tune parameter for the detection or the network generation. − The utilized phase stable scatterers are usually point like scatterers. These are often characterized by a strong and directed radar return which allows this sort of detection principle. − This parameter describes the robustness and the error propagation reduction of the measurements − This parameter is similar to the redundancy and finally describes the robustness and the error propagation reduction of the measurements − The maximum number of relative estimates describes the size of the matrix which needs to be inverted − The maximum number of network points describes the size of the matrix which needs to be inverted − The number of (reference) points influences the accuracy of the final absolute estimation

unit: digital number (count) estimation

estimable height update range unit: m

− The estimation is a frequency estimator and can be realized by a periodogram. The periodogram requires fix bounds of parameters limits.


estimable displacement range unit: mm/year displacement model e.g. linear, non-linearperiodic, non-linear-jump, non-linear-exponential spatial filter size for APS unit: m

temporal filter size for APS unit: days


− The estimation is a frequency estimator and can be realized by a periodogram. The periodogram requires fix bounds of parameters limits. − The phase unwrapping is often solved by a temporal modelling of the displacement. The displacement model is the key parameter for the accuracy of the displacement monitoring. − The APS and noise are computed from the residual phase. The separation can be based on the spatial correlation of the APS. The spatial filter size (slant range and azimuth) tunes this separation. − The residual phase can contain nonlinear motion, APS and noise. The separation can be based on the temporal correlation of the nonlinear motion. The temporal filter size tunes this separation.



5 DELIVERABLES FILE FORMAT The intermediate PSI processing data are delivered in binary files and are stored in simple uncompressed files for simplicity and portability reason. The file format is based on a Sun Raster File (SRF) but is extended for other image data types (e.g. float and 32-bit-integer). Routines to read and write image data into this file format are provided in the IDL language in order to avoid implementation effort and confusion. The files for Terrafirma validation data exchange can be generated and read on Most Significant Byte (MSB) and Least Significant Byte (LSB) hardware. Intel, AMD and DEC are LSB hardware, while SUN Sparc and Motorola are examples for MSB hardware. The layout of the image file is visualized in the following Fig. 9. An image file is composed of three components: the header (red-coloured), the colour table (white) and the image data (green). Only the colour table is optional and the other two components are mandatory.

image header

optional red colour table part optional green colour table part optional blue colour table part line (0) line (1) : :

image data block

: line (height-1)

Fig. 9: Principle structure of the used binary image format called extended Sun Raster Format (SRF). The header has a length of 32 bytes. This part of the file is always in MSB order (i.e. similar to written data on a SUN and not on a PC). In case the data are written on LSB hardware the entries of the header need to be adapted (byte-swapped). The header consists of eight 32-bit signed integer values. These header entries describe the image data type, the dimensions and the optional colour table as follows: The magic number in the first integer is constant 0x59a66a95. This number is the identifier for the SRF format. The second and the third integer store the image dimensions. The fourth integer informs about the bit per pixel of the used data type. The fifth integer represents the number of bytes in the image data block. The sixth integer provides the information on the image data type. The type is set to the value one for all integer



data types. I.e. the bit per pixel information defines the image data type in this case. The following table provides the coding of the different data types: image data type

bit per pixel (entry 4)

data type (entry 6)

byte (unsigned 8 bit)

8

1

short int (signed 16 bit)

16

1

int (signed 32 bit)

32

1

Float

32

99

Double

64

98

short complex (2 x signed 16 bit int)

32

97

float complex

64

96

double complex

128

95

Table 1: coding of the image data type in the sun raster file header The colour table is defined by the following two entries (the seventh entry is the colour table type and the eighth item defines the colour table length). If the colour table type is set to zero no colour table is in the file and the image data follow directly after the header. In case the colour table type has a value different from zero a colour table is assumed. The colour table is stored in the image file only if the colour table type has a value equal to 1 or 2. Otherwise a default colour table needs to be taken and no colour table is read from the file (i.e. the image’s data follow directly after the header in this case). The default colour table is defined to be black–grey–white with a length of 256 colour entries. If the colour table type is set to 1 the number of the eighth header entry colour table length provides the overall length of the following colour table component. I.e. each of the red, green and blue arrays is only 1/3 of this number long. If the colour table type is set to 2 the eighth header entry colour table length provides the size of each of the three (red, green and blue) colour table parts. The components of the colour table are stored in the read, green blue order. They are arrays of bytes each. The lower colour table index is stored first in these arrays. entry

byte position

length

description

comment

1.

0

4 bytes (MSB)

magic number

is a constant identifier: 1504078485 (decimal) 0x59A66A95 (hex)

2.

4

4 bytes (MSB)

image width

number of samples

3.

8

4 bytes (MSB)

image height

number of samples

4.

12

4 bytes (MSB)

bit per pixel

image data are - float: 32 - 32-bit-integer: 1

5.

16

4 bytes (MSB)

data length in bytes

without header and colour



table 6.

20

4 bytes (MSB)

data type

image data are - float: 99 - 32-bit-integer: 32

7.

23

4 bytes (MSB)

colour table type

Is 0 i.e. no colour map for TF

8.

28

4 bytes (MSB)

colour table length

is 0 i.e. no colour map for TF

Table 2: Description of the image header entries The table above describes the header of float and signed 32-bit-integer images only because these two data types are required to exchange the Terrafirma validation data. The image data follow without padding the header data and the eventual colour table data. A colour table is not necessary in the Terrafirma validation project. The image data are stored line by line. In contrast to the standard SRF the data lines are not padded to an even number of samples. I.e. the data are simply stored as a linear byte-stream. The data type of each pixel needs to be the same. The byte-order of the image data depends on the actual hardware. I.e. both (MSB and LSB) are allowed but need not to be mixed inside the image data component and both the integer and floating point data types are affected. In case an image file is transferred from one hardware platform to another the image data component only needs to be byte-swapped. The information on the stored byte order is not available from the header. It is required to provide a hint in the file name (e.g.: file_name_msb.ras or file_name_lsb.ras) in case the image file need to be transferred between different hardware platforms. Standard UNIX tools can be applied to get the dimension information on the image files. E.g. the UNIX command file provides: file slc_5165_msb.ras slc_5165_msb.ras: rasterfile, 5618 x 30378 x 32 standard format image But a usual visualisation tools (e.g. xv, xloadimage) can not display the images correctly in case the image has an odd width due to the removed padding or it is of a non-standard data type.



6 DATA DELIVERABLES The implemented processing chains of the OSPs are different. Therefore, it can be expected that various intermediate processing products are generated. Though the underlying processing principles are similar, it can be very difficult to compare these intermediate data. Nevertheless the comparison of the intermediate data provides a chance to uncover shortcomings and limitations which is the subject of the ongoing validation. This is the reason it is necessary to create a common set of intermediate data even though these are not the standard outputs of the respective processing. The in the following sections defined intermediate products are the minimum required and can be generated without major effort. To allow an objective comparison some questions on the processing details need to be answered additionally. These are collected in a survey similar to an third party audit.

6.1 AUDIT 1) Please describe (briefly) the sequence of processing including a flow chart (single master processing or multi interferogram processing). Part of this section is a description of all modelled parameters and their estimation from the data. 2) Please provide an overview on the tuneable parameters of the PSI processing and a description of their effects and the choice of the actually applied value. (SCR for the PSdetection has influence on the PS density. A low SCR threshold results in a high PS density but in a high risk for PS misdetections). 3) Which scenes are removed from the processing and why? (orbit number and sensor and reason e.g. extreme Doppler values, strong atmospheric effect, corrupted data). This question only applies if the set of scenes has not been fixed. 4) What is the basis for the selection of PS? (coherence in time, coherence in space, dispersion index, SCR, intensity threshold, intensity distribution over time). 5) What is the expected coregistration accuracy? (e.g. 1/10 sample). 6) What is the principle for interferometric pair generation? (single master or short baseline or short time or high coherence). 7) What is the oversampling factor of the SLC data? (e.g. 1 or 2 or 4 or 2 in range and 4 in azimuth). 8) Are the SLC images spectral shift filtered? 9) What is the principle to extract the phase values? Is the phase extracted from interferograms or from the SLCs? Which value is extracted (interpolated at the local peak, the peak of the mean amplitude or simply the value of the image raster (which oversampling is applied))? 10) What is the principle for the network generation (mesh of relative estimates)? (high redundancy or small networks/graphs or most reliable points only or shortest distance between points). 11) What is the principle of the relative to absolute estimation conversion? (least squares integration or path following integration). 12) Which are the reference point(s) for the absolute DEM-update and velocity offsets? Please provide the indexes corresponding to the files ps_x.flt and ps_y.flt. 13) Please report the reason for the reference PS(s) selection.



14) Is a temporal model for the displacement used? If yes – which? 15) What is the basis for the outlier detection used for the time series mask file? The list of questions can be extended depending on the characteristics of the test site. A prescreening would be helpful.

6.2 DELIVERABLE INTERMEDIATE DATA The intermediate data are delivered in the modified SRF format described in section 5 in MSB or LSB format. The file names are composed of a name related to the content and an indicator for the byte order. In the following the MSB byte order is used to describe an example data set resulting in names as e.g. orbits_msb.ras. Please adapt the filename according to the actual hardware. On a PC the same file would be called orbits_lsb.ras. The dimensions of the data file are provided in width x height in samples or number of entries. ASCII files are avoided due to the amount of data. The intermediate data and their annotation are described in the following using an example set of acquisitions as shown in Fig. 10. Each blue dot is related to a radar acquisition and can be identified by its orbit number. In the following the number of scenes is denoted as n_scenes = 7.

Fig. 10: example time baseline diagram of acquisitions to describe the data format

6.3

ORBITS_MSB.RAS

The file orbits_msb.ras is a list of orbit numbers of the used acquisitions. The order does not matter but finally needs to be consistent with the other data. The index to the respective orbit number provides the information on the storage of the other data. It can be advantageous to store the master or super master orbit at the first entry. The data file is of signed 32-bit-integer



i.e. bit per pixel is set to 32 and data type is set to 1 in the SRF header. The dimensions of this file are: n_scenes x 1.

Fig. 11: file orbits_msb.ras is a list of orbits the used radar scenes.

6.4

T_MSB.RAS

Some parameters as e.g. the amplitude of an observation are related to the scene’s acquisition time. Therefore the time span between the radar acquisitions relative to the master or super master scene is provided by the file t_msb.ras. The ordering of the entries is directly related to the orbit entries in the file orbits_msb.ras as is visualized by Fig. 12. The time span is given in units of days and is stored in a float file. I.e bit per pixel is set to 32 and data type is set to 99 in the SRF header.

Fig. 12: The time span between the radar acquisitions relative to the master or super master scene is provided by the file t_msb.ras.

6.5

INTERFEROGRAMS_MSB.RAS

Basis for the PSI processing is the interferometric combination of the radar scenes. Two different concepts are possible the “single master” and the “super master” approach. Both are visualized in Fig. 13 with green arrows indicating the interferometric combinations.



Fig. 13: the two different concepts in the interferometric combinations of radar scenes: left single master approach, right: super master approach The generated interferometric combinations are described by the file interferograms_msb.ras. The data file is of signed 32-bit-integer i.e. bit per pixel is set to 32 and data type is set to 1 in the SRF header. The dimensions of this file are: n_interferograms x 2. The entries are the index into the data file orbits_msb.ras. The master scene is the first line of the two. The Fig. 14 presents an example for the two approaches.

Fig. 14: description of the interferometric combinations. The entries are indices into the file orbits_msb.ras (see Fig. 11).

6.6

DT_MSB.RAS

The interferometric phase values need to be related to the time span between the interferometric acquisitions. In principle this information can easily be derived from the data files t_msb.ras and interferograms_msb.ras. Nevertheless a special file with this information with the name



dt_msb.ras should be created by the OSPs. The dimensions of this file are: n_interferograms x 1. The time span is given in units of days and is stored in a float file. I.e bit per pixel is set to 32 and data type is set to 99 in the SRF header.

Fig. 15: The file dt_msb.ras contains the time span between the master and the slave acquisition for each generated interferometric pair. Presented is an example for the super master approach.

6.7

PS_X_MSB.RAS AND PSY_MSB.RAS

The interferometric phase is only used at phase stable locations. These slant range coordinates of the persistent scatterers are reported in the files ps_x_msb.ras and ps_y_msb.ras. The slant range coordinate system of the master or super master scene is used. The x-coordinate is associated with the slant range direction and is stored in the file ps_x_msb.ras. The ycoordinate corresponds to the azimuth direction and is given in the file ps_y_msb.ras. The cropped1 slant range image coordinate system starts with index (0,0) at the first range time and first azimuth time sample of the cropped SLC according to Fig. 16. The slant range position is given in units of oversampled (if applicable) samples and is stored in a float file. I.e bit per pixel is set to 32 and data type is set to 99 in the SRF header.

1

The intention is to use the cropped areas only for the description of the coordinates. I.e. The coordinate system starts with (0,0) in the first range time and azimuth time of the cropped area. The first range and azimuth time of the cropped area are given similar to the total scenes first range and azimuth time at the center of the first sample. Please, do not use the total scenes first range and azimuth time as the reference for the PS location annotation. In principle, a systematic error (bias) in the location annotation is not a problem for the process validation - however a correct location annotation is a nice support. To simplify the tricky work of the OSPs generating these data, the copped master SLC data (single look and oversampled by a factor of two) are provided to all of them. These data are intended to help them selecting and processing exactly the same cropped area.



Fig. 16: Visualization of the used slant range coordinate system: The green dots represent exemplarily persistent scatterers and the blue stars represent the location of the integer grid of the used slant range coordinate system. The square areas of one and the same grey can be considered to be a resolution cell of the radar in case no oversampling is applied. The processing systems can oversample the data. The persistent scatterer locations are then related to the oversampled image coordinates. The oversampling factor in range and azimuth needs to be reported. The original and the oversampled coordinates systems are not mutually shifted. Fig. 17 shows the relation between the two coordinate systems and provides a simple check for this specification for each processing system. The following transformation between the original SLC coordinates (x, y )SLC and the oversampled coordinates ( x, y )ovs for the comparison will be applied:

(x, y )ovs = ovs ⋅ (x, y )SLC

(equ. 1)

The files ps_x_msb.ras and ps_y_msb.ras are build up of float values (i.e. bit per pixel is set to 32 and data type is set to 99 in the SRF header). That is the persistent scatterer locations can be reported with sub-pixel accuracy. The dimensions of the files need to be the same and correspond to the number of persistent scatterers n_ps. In case the actual processing system is



working on the interferograms directly i.e. avoiding a point scatterer analysis (e.g. PTA) the respective slant range coordinates are reported on the resolution cell centers (the blue stars in Fig. 16). These positions correspond directly to the integer image coordinates i.e. no 0.5 needs to be added.

Fig. 17: Coordinate system relation between the original sampling (black) and the oversampled (blue) data values. The oversampling factor in this example is two. The oversampled (interpolated) values are the same as the originally given data at each second data point.

Fig. 18: Description of the slant range locations of the persistent scatterers in the files ps_x_msb.ras and ps_y_msb.ras. The length is the number of PS (The drawing corresponds to the example from Fig. 16 with n_ps=4).


6.8


PHI_MSB.RAS, B_MSB.RAS, APS_IFGRM_MSB.RAS AND RESIDUAL_MSB.RAS

Some intermediate data are related to the interferometric combinations. These are characterized by the interferometric time separation dt (dt_msb.ras), the persistent scatterer locations (ps_x_msb.ras, ps_y_msb.ras) and the height to phase conversion factors b in the file b_msb.ras, the APS per interferogram apsifgrm in the file aps_ifgrm_msb.ras and the residual phase residualifgrm in file residual_msb.ras. The height to phase conversion factor can vary over slant range and azimuth. Therefore, this parameter is stored in the same data layout as the interferometric phase values. Consequently, each persistent scatterer is characterized by its own height to phase conversion factor which has the unit rad per meter. The interferometric time separation is constant for each line describing an irregular sampled interferogram and each column describes a single slant range location (usually a single persistent scatterer). The following equation describes the decomposition of the interferometric phase ϕ ifgrm :

ϕ ifgrm = b ⋅ hPS +

4 ⋅π

λ

⋅ dt ⋅ v PS + apsifgrm + residualifgrm

(equ. 2)

In the equation above, hPS (in m and b in rad/m) and v PS (in mm/year, dt im years and λ in mm) denote the finally estimated height and velocity of a single persistent scatterer. ϕifgrm (phi_msb.ras) is the measured interferometric phase. It does not matter how it is created: via PTA and a phase subtraction or via an interferogram generation by conjugate complex multiplication of two SLCs. The right hand side terms of equ. 2 are given by the observation geometry ( b and dt ), the estimates ( hPS and v PS ) and intermediate processing products apsifgrm and residualifgrm (both in rad). Fig. 19 provides an example for the relation of interferometric data on a single master example. The super master approach results in a similar data layout. The dimensions of the data files are: n_ps x n_interferograms. The phase values (interferometric phase, APS and residual phase) are given in rad and are stored in a float file. I.e bit per pixel is set to 32 and data type is set to 99 in the SRF header. In case additional effects are modelled both the estimated parameter (e.g. the azimuth sub-pixel location) and the parameters from which it is estimated (e.g. the Doppler centroid frequency difference) needs to be provided. The file names should be indicators for the content (e.g. az_pos_msb.flt and delta_fdc_msb.flt could be a good choice. The principle and the units of the data need to be described in the audit in the section. The extended sun raster file data type should be appropriate.



Fig. 19: Example data relation for interferometric data on a single master example. The super master approach results in a similar data layout.

6.9

AMPL_MSB.RAS, SCR_MSB.RAS, APS_SLC_MSB.RAS, TIME_SERIES_MSB.RAS AND TIME_SERIES_MASK_MSB.RAS

Some intermediate data are related to the SLC scenes. These are characterized by the (super) master related acquisition time t (t_msb.ras) and the persistent scatterer locations (ps_x_msb.ras, ps_y_msb.ras). The scatterers amplitude (ampl_msb.ras), the APS per scene apsslc in the file aps_slc_msb.ras and the scatterers phase stability (e.g. the signal to clutter ratio) in the file scr_msb.ras are such. The PS time series of the LOS displacement (unit rad) in the file time_series_msb.ras is one of the main processing outputs for the processing validation. For each line the time separation is constant related to the (super) master scene describing an acquisition and each column describes a single slant range location (usually a single persistent scatterer). Fig. 20 provides an example of the data relation for scene related data. These files are values which can describe the evolution of a property related to the acquisition time. The dimensions of the data files are: n_ps x n_scenes. The amplitude values in ampl_msb.ras can be given as a relative digital number or as a fully calibrated backscatter intensity e.g. in dB but the unit and eventually the physical meaning e.g. radar brightness β 0 or radar backscatter coefficient σ 0 needs be reported. The APS values are given in rad. All data files are stored in float. I.e bit per pixel is set to 32 and data type is set to 99 in the SRF header. The values of the PS LOS displacement (time_series_msb.ras) can be masked. This allows to remove outliers and invalid data in the time series from the validation. The outlier detection i.e. the masking is performed by the OSPs. The mask is a file in the same layout as the file



time_series_msb.ras but the data type is integer (signed 32 bit: bit per pixel is 32 and data type is 1). A two dimensional index in the time series file corresponds one to one in the mask file. The mask file is named time_series_mask_msb.ras. A value in the mask file different from zero indicates invalid data. Using bit-fields to indicate different causes is allowed and can be reported. In case the RAW data are focused by the OSP using their own Doppler centroid frequency estimates these values need to be delivered in a similar format. I.e. polynomials are evaluated at each stable scatterer location. The unit of the data value is Hz and the pixel type is float. The file name is fdc_msb.ras.

Fig. 20: Example data relation for scene related data


6.10


GRAPH_MSB.RAS

A network is generated, in case relative estimates between phase stable scatterers are estimated. This network is described by the file graph_msb.ras. The data file is of signed 32bit-integer i.e. bit per pixel is set to 32 and data type is set to 1 in the SRF header. The dimensions of this file are: n_ps_pairs x 2. The entries are the indices into the data files ps_x_msb.ras and ps_y_msb.ras. The network is described by a directed graph: the stable scatterers are the vertices and the estimates are the edges. The first line of the two describes the source point and the second line describes the destination point of a relative estimation. Fig. 21 presents an example graph for the points from Fig. 16. The corresponding file graph_msb.ras is shown in Fig. 22. In case the actual processing does not generate relative estimates a short comment is appreciated at least in the audit section on the processing flow chart how the APS is handled.

Fig. 21: Visualisation of a possible network of relative estimates.



Fig. 22: Example for the file graph_msb.ras. The example corresponds to the network in Fig. 21.

6.11

COH_REL_MSB.RAS, V_REL_MSB.RAS AND H_REL_MSB.RAS

The relative estimates and their parameters are described related to the file graph_msb.ras. Each estimate is stored in a vector (dimensions: n_ps_pairs x 1) where the index is related to the PS-pair described by the file graph_msb.ras. Fig. 23 provides an example for this relation. The file coh_rel_msb.ras contains the coherence of the relative estimation:

γϕ =

1 N j ⋅(ϕirelative −ϕimodel ) ⋅ ∑e N i =1

N is the number of phase values,

(equ. 2)

relative

ϕi

and

model

ϕi

are the phases of the i-th interferogram relative

between two PS and the respective modelled phase. The modelled phase is the sum of the respective estimated relative DEM-update phase ϕitopo , the relative displacement phase ϕidefo and the relative APS phase ϕiatmo :

ϕimodel = ϕ idefo + ϕitopo + ϕiatmo

(equ. 3)

Advanced processing systems can additionally model other effects. This is allowed but should be reported including the parameters in the audit describing the processing. Moreover, the additionally modelled phase is a deliverable and the data layout is similar to the aps_ifgrm_msb.ras file (section 6.8). The filename needs to be unique and should be an indicator for the data entries.



In case no coherence is estimated during the processing it is appreciated to provide an equivalent measurement describing e.g. the goodness of fit or the quality of the relative estimation. The files v_rel_msb.ras and h_rel_msb.ras provide the estimates of the displacement rate vrel in mm/year and the height update hrel in m.

Fig. 23: The relative estimates and their parameters are described related to the file graph_msb.ras. Each estimate is stored in a vector (dimensions: n_ps_pairs x 1) where the index is related to the PS-pair described by the file graph_msb.ras.

6.12

COH_ABS_MSB.RAS, V_ABS_MSB.RAS AND H_ABS_MSB.RAS

The absolute estimates and their parameters are described related to the files ps_x_msb.ras and ps_y_msb.ras. Each estimate is stored in a vector (dimensions: n_ps x 1) where the index is related to the PS location described by the file ps_x_msb.ras and ps_y_msb.ras. Fig. 24 provides an example for this relation. The file coh_abs_msb.ras contains the coherence of the absolute estimation and is defined as:

γϕ =

1 N j ⋅(ϕiifgrm −ϕimodel ) ⋅ ∑e . N i =1

N is the number of interferograms,

(equ. 4)

ifgrm

ϕi

and

model

ϕi

are the phase of the i-th interferogram and the

respective modelled phase. The modelled phase is the sum of the respective estimated DEMupdate phase ϕitopo , the displacement phase ϕidefo and APS phase ϕiatmo at the respective point:


ϕimod el = ϕidefo + ϕitopo + ϕ iatmo .


(equ. 5)

Advanced processing systems can additionally model other effects. This is allowed but should be reported including the parameters in the audit describing the processing. Moreover, the modelled phase is a deliverable and the data layout is similar to the aps_slc_msb.ras file (section 6.9). The filename should be unique and be an indicator for the data entries.

Fig. 24: data layout of the absolute estimates at the PS-locations.

6.13 IMAGE LAYERS In order to complement the data basis for the assessment the following image layers of data need to be delivered. 6.13.1 AMPL_MEAN_MSB.RAS This file (ampl_mean_msb.ras) is an image of the mean amplitude (incoherent average) in at least one-look resolution (integer oversampling factor is allowed). The image dimensions correspond to the master SLC and the image coordinates are one to one related to the (oversampled) master’s slant range coordinates. The amplitude values can be given as a relative digital number or as a fully calibrated intensity e.g. in dB but the unit and eventually the physical meaning e.g. radar brightness β 0 or radar backscatter coefficient σ 0 should be reported. The data values are stored as float. I.e. bit per pixel is set to 32 and data type is set to 99 in the SRF header.



6.13.2 SCR_MSB.RAS The file scr_msb.ras is an image of the expected phase stability for each point in the scene. In case no SCR is estimated in the actual processing system the value which is used for the PS detection should be delivered instead. It is appreciated to provide some information on this deliverable in the audit section. The image dimensions correspond to the master SLC and the image coordinates are one to one related to the (oversampled) master’s slant range coordinates. The data values can be given in any unit but the unit should be reported and the relation to the expected phase stability should be provided. The phase stability values are stored as float. I.e. bit per pixel is set to 32 and data type is set to 99 in the SRF header. 6.13.3 SLC_MASTER_MSB.RAS, SLC_MASTER_OVS2_MSB.RAS AND SLC_DDDDD_MSB.RAS Some single look complex images need to be delivered. They are used to check the phase stability of the focussing. The master’s SLC scene is stored in the file slc_master_msb.ras. In case the actual processing system uses oversampled scenes the oversampled master SLC needs to be delivered additionally in the file slc_master_ovs2_msb.ras. The number in the file name provides the oversampling factor. All SLC files are of type short integer complex. I.e. the data values are stored as signed 16-bit-integer-16-bit-integer tupels. The first part of the pair corresponds to the real part and the second to the imaginary part of the sample. I.e. bit per pixel is set to 32 and data type is set to 97 in the SRF header. A slave SLC can be named using the orbit number and the oversampling description. E.g. the SLC of the orbit 5165 and with an oversampling of two would be named slc_5165_ovs2_msb.ras. The image coordinates are directly related to the (oversampled) master’s slant range coordinates, i.e. the slave scene is coregistered already. The scaling of the amplitude should be similar to the standard CEOS format to have only little quantisation effects. In case of doubts on an appropriate scaling these files can be delivered in float complex data format. Please report this case.

6.14 OVERVIEW ON DELIVERABLE FILES The following variables denote the number of PS:

n_ps

number of rel. estimates: n_ps_pairs number of scenes:

n_scenes

number of interferograms: n_ifgrms file name

dimension

data type

description

orbits_msb.ras

n_scenes x 1

32-bit integer

list of orbit numbers of the used scenes

t_msb.ras

n_scenes x 1

32-bit float

time span in days related to the master scene

interferograms_msb.ras

n_ifgrms x 2

32-bit integer

indexes into orbits_msb.ras and t_msb.ras describing master and slave scenes

dt_msb.ras

n_ifgrms x 1

32-bit float

interferometric time separation in days corresponding to the file



interferograms_msb.ras ps_x_msb.ras

n_ps x 1

32-bit float

range coordinates of phase stable points in units of (oversampled) samples

ps_y_msb.ras

n_ps x 1

32-bit float

azimuth coordinates of phase stable points in units of (oversampled) samples

phi_msb.ras

n_ps x n_ifgrms

32-bit float

measured interferometric phase at the PS locations in rad

b_msb.ras

n_ps x n_ifgrms

32-bit float

height to phase conversion at the PS locations in rad/m

aps_ifgrm_msb.ras

n_ps x n_ifgrms

32-bit float

interferometric APS at the PS locations in rad

residual_msb.ras

n_ps x n_ifgrms

32-bit float

interferometric residual phase at the PS locations in rad

ampl_msb.ras

n_ps x n_scenes

32-bit float

amplitude or intensity at the PS locations (please provide unit)

fdc_msb.ras

n_ps x n_scenes

32-bit float

Doppler centroid frequency at the PS locations for each acquisition in Hz

scr_msb.ras

n_ps x n_scenes

32-bit float

signal-to-clutter ratio at the PS locations or similar expectation on phase stability

aps_slc_msb.ras

n_ps x n_scenes

32-bit float

APS of the scenes at the PS locations in rad

graph_msb.ras

n_ps_pairs x 2

32-bit integer

indexes into ps_x_msb.ras and ps_y_msb.ras describing the graph of relative estimates

coh_rel_msb.ras

n_ps_pairs x 1

32-bit float

coherence (0..1) of relative estimates related to the file graph_msb.ras

v_rel_msb.ras

n_ps_pairs x 1

32-bit float

estimated relative linear velocities in mm/year at the edges described by graph_msb.ras

h_rel_msb.ras

n_ps_pairs x 1

32-bit float

estimated relative DEM update in m at the edges described by graph_msb.ras

coh_abs_msb.ras

n_ps x 1

32-bit float

coherence (0..1) of absolute estimations related to ps_x_msb.ras and ps_y_msb.ras

v_abs_msb.ras

n_ps x 1

32-bit float

estimated absolute velocities in mm/year at the PS locations i.e. related to ps_x_msb.ras and

ps_y_msb.ras



h_abs_msb.ras

n_ps x 1

32-bit float

estimated DEM-update in m at the PS locations i.e. related to ps_x_msb.ras and ps_y_msb.ras

time_series_msb.ras

n_ps x n_scenes

32-bit float

estimated LOS displacement in rad at the PS locations sampled at the acquisition times

time_series_mask_msb.ras

n_ps x n_scenes

32-bit integer

mask corresponding to file time_series_msb.ras (0=valid; invalid otherwise)

ampl_mean_msb.ras

master SLC dim

32-bit float

incoherent average of intensity, unit depends on calibration: please provide the unit

ampl_mean_ovs2_msb.ras

oversampled master SLC dim

32-bit float

incoherent average of intensity, unit depends on calibration: please provide

scr_msb.ras

(oversampled) master SLC dim

32-bit float

expected phase stability or similar value used for PS detection (please provide unit)

slc_dddd_ovs2_msb.ras

(oversampled) master SLC dim

16-bit/16-bit (short) complex

oversampled single look complex scenes (dddd is replaced by the orbit number)

slc_master_msb.ras

master SLC dim


not oversampled single look complex master scene

slc_master_msb_ovs.ras

oversampled master SLC dim


oversampled single look complex master scene

processing parameter matix

ASCII /Word doc

The files should be delivered by ftp or DVD. No directory structure is required i.e. the files can be located in the root directory of the DVD or in the OSPs ftp directory.



7 PROCESS ANALYSIS All reported numbers, plots and visualisations are anonymous. The first activity of DLR is the generation of a matrix describing the several validation deliverables of the different OSPs. It will provide an overview on the applicability of the intermediate data to the OSPs processing chain and the cooperation of the respective OSP to generate them. Deliverable orbits_msb.ras t_msb.ras interferograms_msb.ras dt_msb.ras ps_x_msb.ras ps_y_msb.ras phi_msb.ras b_msb.ras aps_ifgrm_msb.ras residual_msb.ras ampl_msb.ras fdc_msb.ras scr_msb.ras aps_slc_msb.ras graph_msb.ras coh_rel_msb.ras v_rel_msb.ras h_rel_msb.ras coh_abs_msb.ras v_abs_msb.ras h_abs_msb.ras time_series_msb.ras time_series_msb.ras ampl_mean_msb.ras ampl_mean_ovs2_msb.ras scr_msb.ras slc_dddd_ovs2_msb.ras slc_master_msb.ras

OSP1

OSP2

OSP3

OSP4



slc_master_msb_ovs.ras processing parameter matrix

The following analysis tasks are intended. They are provided as examples for the use of the deliverables. At the moment, only a coarse specification of the assessment is intended. The reason is to allow flexibility to react on (systematic) effects which will be observed in the provided data. I.e. the assessments can be adapted if necessary. Scatter plots are considered a typical tool to reveal systematic effects from the data of two different processing systems. Other helpful assessments are the shape and parameters e.g. mean and standard deviation of likelihood functions (derived from histograms) or variograms. The significance of the observed differences is judged on basis of the impact on the final LOS displacement estimation (in slant range only). I.e. this displacement estimation is considered the main output of the processing. Deviations in describing other parameters e.g. APS, radar return intensity or phase stability will be reported but will be interpreted only related to their influence on the final slant range displacement estimation. For instance, the height update estimation has in fact an impact on the final geocoded location accuracy. But there is no influence on the slant range only output. The processing chain validation therefore reports DEM update deviations but considers these as not significant.

7.1 CHECK OF DATA DELIVERY Input: •

All *_msb.ras or *_lsb.ras files

•

Answers from the audit

•

Processing parameter matrix

Check: •

Check for correct data format (e.g. data type, byte-order, file format)

•

Check for consistent file dimensions

•

Check for correct units

Output: •

Ok for detailed assessment for each OSP or

•

Clarification questions to OSPs or

•

Request for delivery update to OSP

•

Table on applicability of the validation deliverables for the respective OSP processing systems (please see above)

7.2 OBSERVATION PARAMETER CHECK Input: •

t_msb.ras and dt_msb.ras of all the OSPs

•

b_msb.ras of all the OSPs



Check: •

Check for deviations in the parameters describing the observation

•

Visualize the deviations

Output: •

Plot relative deviation of the observation parameters between OSPs

7.3 MASTER SLC PROCESSING CHECK Input: •

slc_master_msb.ras and slc_xxxxx.ras of all the OSPs (TBD: slave scene needs to be selected)

Check: •

Check extend and coregistration of the SLCs

•

Generate interferograms

•

Visualize the deviations

The idea is to compare standard SLCs delivered by the PAFs with the SLCs processed by the OSPs from RAW data. Standard SLCs are not oversampled. Output: •

phase deviation caused by focussing between OSPs

7.4 OVERSAMPLING AND COORDINATES TEST Input: •

ampl_mean_msb.ras and ampl_mean_ovs2.ras

Check: •

Check data for correct coordinate system

•

Plot the data values similar to Fig. 17

Output: •

Confirmation for compatible coordinate systems

7.5 COREGISTRATION ACCURACY 7.5.1

RELATIVE COREGISTRATION DEVIATION FROM MEAN MAP

Input: •

ampl_ovs2_mean_msb.ras images of all the OSPs

Check: •

Select some point scatterers distributed over range and azimuth


•


Perform point target analysis (peak location) in each mean image

Output: • 7.5.2

Plot relative deviation between OSPs along range and azimuth RELATIVE COREGISTRATION DEVIATION FROM PS-LOCATION FILES

Input: •

ampl_ovs2_mean_msb.ras of a single OSP

•

ps_x_msb.ras and ps_y_msb.ras of a single OSP

Check: •

Select some point scatterers distributed over range and azimuth given in the files ps_x_msb.ras and ps_y_msb.ras

•

Perform point target analysis (peak location) in mean image (ampl_ovs2_mean_msb.ras)

Output: •

Plot relative deviation along range and azimuth for each OSP

7.6 RELATIVE INTERFEROMETRIC PHASE DEVIATIONS Input: •

phi_msb.ras of each OSP

•

ps_x_msb.ras and ps_y_msb.ras of each OSP

Check: •

Compare the extracted phase values using the common set of PS-points between the OSPs. How to find the common PS-points between the OSPs? Initially, PSs within a radius of 0.5 natural samples are considered one and the same scatterer. The distance threshold of 0.5 samples will be adjusted according to the delivered data.

•

Check Audit for details on oversampling and the phase extraction algorithm

Output: •

Visualization of deviations between the OSPs (e.g. correlation plot)

•

A mean coherence and a standard deviation for the extracted interferometric phase will be provided if possible

7.7 APS AND ORBIT TRENDS 7.7.1

DOMINANT INTERFEROMETRIC PHASE CONTRIBUTION

Input: •

phi_msb.ras of a single OSP

•




Check: •

Create images of the irregular sampled interferometric phase of previously defined interferometric combinations

•

The interferograms have typical dominant contributions e.g. APS and orbit errors

•

Perform visual interpretation of the dominant effect

Output: •

Images of typical interferograms for each OSP

7.8 SCENE CALIBRATION 7.8.1

SCENE CALIBRATION COMPARED TO DLR

Input: •

ampl_msb.ras of a single OSP

•


Check: •

check for calibration type (relative or absolute)

•

compare with DLR’s absolute calibration

Output: •

Plot of different persistent scatterers over time (should have the similar evolution in time)

•

Visualize deviations (e.g. correlation plot)

7.8.2

SCENE CALIBRATION OSPS COMPARED TO EACH OTHER

Input: •

ampl_msb.ras of each OSP

•


Check: •

check for calibration type (relative or absolute)

•

check for significant deviation

Output: •

Visualize deviations of calibration between the OSPs

7.9 PS DETECTION 7.9.1 Input:

PS DENSITY COMPARED TO EACH OTHER


•


•

scr_msb.ras of each OSP

•



Check: •

check for significant deviation in PS density

Output: • 7.9.2

PS density value for each OSP related to the expected phase stability SPATIAL PS DISTRIBUTION COMPARED TO EACH OTHER

Input: •


•


•


Check: •

check for significant deviation in PS distribution

Output: •

7.9.3

Characterisation of the spatial distribution of the identified PS for each OSP related to the expected phase stability PS DENSITY HISTOGRAM COMPARED TO EACH OTHER

Input: •


•


•


Check: •

check for significant deviation in PS density

Output: •

7.9.4

comparison of the estimated PS frequency for each OSP related to the expected phase stability PS MISDETECTION CHECK

Input: •


Check: •

check for mis-detected PS due to sidelobes



Output: • 7.9.5

number of misdetected PS RELATIVE PS-LOCATION DEVIATION FROM SCATTERER LOCATION FILES

Input: •

ps_x_msb.ras and ps_y_msb.ras of all OSPs

Check: •

assessment of relative deviation in range and azimuth

Output: •

Plot relative deviation in PS location detection between OSPs along range and azimuth

7.10 DEM AND DISPLACEMENT UPDATE TEST 7.10.1 NETWORK ASSESSMENT Input: •

ps_x_msb.ras and ps_y_msb.ras of all OSPs

•

graph_msb.ras of all OSPs

Check: •

Assessment of the network of relative estimates

•

Check for redundancy of estimates

•

Check for maximum distance between estimation points

Output: •

Visualisation of the networks

•

Comparison of network parameters

7.10.2 RELATIVE DEM UPDATE CONSISTENCY Input: •


•

graph_msb.ras of each OSP

•

h_rel_msb.ras of each OSP

Check: •

Assessment of the inconsistencies of relative DEM update estimates

Output: •

Visualisation of the DEM update residuals

•

Description of the effects



7.10.3 RELATIVE MEAN VELOCITY CONSISTENCY Input: •


•


•

v_rel_msb.ras of each OSP

Check: •

Assessment of the inconsistencies of relative displacement estimates

Output: •

Visualisation (e.g. scatter plots) of the displacement residuals

•


7.10.4 RELATIVE DEM UPDATE DEVIATIONS BETWEEN OSPS Input: •


•


•

h_rel_msb.ras of each OSP

Check: •

Assessment of the deviations of relative DEM update estimates

Output: •

Visualisation of the DEM update e.g. by scatterplots

•


7.10.5 RELATIVE MEAN VELOCITY DEVIATIONS BETWEEN OSPS Input: •


•


•

v_rel_msb.ras of each OSP

Check: •

Assessment of the deviations of relative mean velocity estimates

Output: •

Visualisation of the mean velocity deviations e.g. by scatterplots

•




7.10.6 RELATIVE COHERENCE COMPARISON Input: •


•


•

coh_rel_msb.ras of each OSP

Check: •

Comparison of the coherence of the relative estimates between the OSPs

Output: •

Visualisation of the coherence deviations

•


7.10.7 RELATIVE APS AND RESIDUAL PHASE COMPARISON Input: •


•


•

aps_ifgrm_msb.ras of each OSP

•

residual_msb.ras of each OSP

Check: •

Comparison of the APS of the relative estimates between the OSPs and

•

Comparison of the residual phase of the relative estimates between the OSPs

Output: •

Visualisation of the deviations

7.10.8 ABSOLUTE APS PHASE COMPARISON Input: •


•

aps_slc_msb.ras of each OSP

Check: •

Comparison of the APS of the single acquisitions between the OSPs

Output: •


7.10.9 ABSOLUTE VELOCITY COMPARISON Input:


•


•

v_abs_msb.ras of each OSP


Check: •

Comparison of the absolute displacement estimations between the OSPs

•

Check for deviations caused by different reference points

Output: •

Visualisation of the deviations (e.g. scatterplots)

•

Visualisation of the spatial shape of the displacements

•

Analysis or description of the effects

7.10.10 ABSOLUTE DEM UPDATE COMPARISON Input: •


•

h_abs_msb.ras of each OSP

Check: •

Comparison of the absolute DEM Update estimations between the OSPs

•

Check for deviations caused by different reference points

Output: •


7.10.11 ABSOLUTE COHERENCE COMPARISON Input: •


•

coh_abs_msb.ras of each OSP

Check: •

Comparison of the absolute coherence estimations between the OSPs

Output: •


7.10.12 COMPARISON OF TIME SERIES OF SELECTED POINTS Input: •


•

t_msb.ras of each OSP

•

time_series_msb.ras of each OSP



Check: •

Comparison of the absolute coherence estimations between the OSPs

Output: •


7.10.13 ABSOLUTE DISPLACEMENT DETECTION COMPARISON Input: •


•

v_abs_msb.ras of each OSP

Check: •

binning (quantisation) of the absolute displacements to check the “displacement risk” detection

•

Comparison of the absolute displacement estimations between the OSPs using thresholds

Output: •

Traffic light maps of displacement

•

Visualisation of the spatial shape of the displacements

•

Analysis or description of the effects



Appendix

7.11 WRITE ROUTINES 7.11.1 WRITE_BYTE ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_byte.pro -------------------------------------------------------------------------AUTHOR : Nico Adan -------------------------------------------------------------------------CONTENT : write unsigned char extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_byte.pro,v 1.1 2007/05/03 20:45:41 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_byte, afile_name, aimage, r=r, g=g, b=b; img_info = Size( aimage ); case img_info[0] of 1: begin ;// dim xdim ydim type n-elements img_info = [ 2, img_info[1], 1, img_info[2], img_info[1] ]; end 2: begin ;// nothing to do end else: begin Print, 'write_byte: need 2 dimensional array'; Return; end endcase if img_info[3] NE 1 then begin print, 'write_byte: WARNING: change data to byte'; aimage = Byte( aimage ); end h = LonArr( 8 ); h[0] = '59A66A95'x; h[1] = img_info[1]; h[2] = img_info[2]; h[3] = 8; h[4] = 0; h[5] = 1; h[6] = 0; h[7] = 0; if N_Elements( r ) NE 0 then begin h[6] = 1; h[7] = N_Elements( r ) * 3; endif if 'LSB' EQ Sys_Byte_Order() then begin h = Swap_Endian( h ); endif OpenW, fd, afile_name, /GET_LUN; WriteU, fd, h; if N_Elements( r ) NE 0 then begin WriteU, fd, r; WriteU, fd, g; WriteU, fd, b; endif WriteU, fd, aimage; Close, fd; Free_Lun, fd; end



7.11.2 WRITE_INT16 ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_int16.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write short int extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_int16.pro,v 1.1 2007/05/03 20:45:42 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_int16, afile_name, aimage img_info = Size( aimage ); case img_info[0] of 1: begin ;// dim xdim ydim type n-elements img_info = [ 2, img_info[1], 1, img_info[2], img_info[1] ]; end 2: begin ;// nothing to do end else: begin print, 'write_int: need 2 dimensional array'; return; end endcase if img_info[3] NE 2 then begin print, 'write_int: WARNING: change data to short int'; aimage = Fix( aimage ); end h = LonArr( 8 ); h[0] = '59A66A95'x; h[1] = img_info[1]; h[2] = img_info[2]; h[3] = 16; h[4] = 0; h[5] = 1; h[6] = 0; h[7] = 0; OpenW, fd, afile_name, /GET_LUN; if ( 'LSB' EQ Sys_Byte_Order() ) then begin ByteOrder, h, /HTONL; endif WriteU, fd, h; WriteU, fd, aimage; Close, fd; Free_Lun, fd; end

7.11.3 WRITE_INT32 ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_int32.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write int (32bit) extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_int32.pro,v 1.1 2007/05/03 20:45:42 nadam Exp $ **************************************************************************



;// ************************************************************************** ;// ************************************************************************** pro write_int32, afile_name, aimage img_info = Size( aimage ); case img_info[0] of 1: begin ;// dim xdim ydim type n-elements img_info = [ 2, img_info[1], 1, img_info[2], img_info[1] ]; end 2: begin ;// nothing to do end else: begin Print, 'write_long: need 2 dimensional array'; Return; end endcase if img_info[3] NE 3 then begin Print, 'write_long: WARNING: change data to int (32 bit)' aimage = Long( aimage ) end h = LonArr( 8 ) h[0] = '59A66A95'x h[1] = img_info[1] h[2] = img_info[2] h[3] = 32 h[4] = 0 h[5] = 1 h[6] = 0 h[7] = 0 OpenW, fd, afile_name, /GET_LUN; if ( 'LSB' EQ Sys_Byte_Order() ) then begin ByteOrder, h, /HTONL; endif WriteU, fd, h; WriteU, fd, aimage; Close, fd; Free_Lun, fd; end

7.11.4 WRITE_FLT ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_flt.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write float extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_flt.pro,v 1.2 2007/05/03 21:33:52 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_flt, afile_name, aimage img_info = Size( aimage ); case img_info[0] of 1: begin ;// dim xdim ydim type n-elements img_info = [ 2, img_info[1], 1, img_info[2], img_info[1] ]; end 2: begin ;// nothing to do end else: begin Print, 'write_flt: need 2 dimensional array' Return; end



endcase if img_info[3] NE 4 then begin print, 'write_flt: WARNING: change data to float' aimage = Float( aimage ) end h = LonArr( 8 ); h[0] = '59A66A95'x h[1] = img_info(1) h[2] = img_info(2) h[3] = 32 h[4] = 0 h[5] = 99 h[6] = 0 h[7] = 0 OpenW, fd, afile_name, /GET_LUN if ( 'LSB' EQ Sys_Byte_Order() ) then begin ByteOrder, h, /HTONL endif WriteU, fd, h WriteU, fd, aimage Close, fd Free_Lun, fd end

7.11.5 WRITE_DBL ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_dbl.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write double extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_dbl.pro,v 1.1 2007/05/03 20:45:41 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_dbl, afile_name, aimage img_info = Size( aimage ); case img_info[0] of 1: begin ;// dim xdim ydim type n-elements img_info = [ 2, img_info[1], 1, img_info[2], img_info[1] ]; end 2: begin ;// nothing to do end else: begin Print, 'write_dbl: need 2 dimensional array'; Return; end endcase if img_info[3] NE 5 then begin Print, 'write_dbl: WARNING: change data to double'; image = Double( image ); end h = LonArr( 8 ); h(0) = '59A66A95'x; h(1) = img_info[1]; h(2) = img_info[2]; h(3) = 64; h(4) = 0; h(5) = 98; h(6) = 0; h(7) = 0;



OpenW, fd, afile_name, /GET_LUN if ( 'LSB' EQ Sys_Byte_Order() ) then begin ByteOrder, h, /HTONL; endif WriteU, fd, h; WriteU, fd, aimage; Close, fd; Free_Lun, fd; end

7.11.6 WRITE_SCPLX ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_scplx.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write short int complex extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_scplx.pro,v 1.1 2007/05/03 20:45:42 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_scplx, afile_name, aimage s = Size( aimage ); h = LonArr(8) h[0] = '59A66A95'xL; // 956AA659 h[1] = s[1]; h[2] = s[2]; h[3] = 32; h[4] = Long(s[1]) * s[2] * 4; h[5] = 97; h[6] = 0; h[7] = 0; arch = Sys_Byte_Order(); if ( 'LSB' EQ arch ) then ByteOrder, h, /HTONL OpenW, fd, afile_name, /GET_LUN WriteU, fd, h; if ( 'LSB' EQ arch ) then ByteOrder, h, /NTOHL block_size = 512; block = IntArr( s[1] * 2, block_size ); idx_re = IndGen( h[1] ) * 2 idx_im = idx_re + 1; line = IntArr( 2 * h[1] ); block_idx = 0L; mod_block_idx = 0L; for y = 0L, s[2]-1 do begin line[idx_re] = Float(aimage[*,y]) line[idx_im] = Imaginary(aimage[*,y]) mod_block_idx = block_idx mod block_size; block[ *, mod_block_idx ] = line; if ( mod_block_idx EQ (block_size-1) ) then begin WriteU, fd, block; endif block_idx = Temporary( block_idx ) + 1; endfor ;// write remaining data in block: if ( (mod_block_idx NE 0 ) AND $ (mod_block_idx NE (block_size-1)) ) then begin WriteU, fd, block[*,0:mod_block_idx]; endif Close, fd



Free_Lun, fd end

7.11.7 WRITE_FCPLX ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : write_fcplx.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write float complex extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_fcplx.pro,v 1.1 2007/05/03 20:45:41 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_fcplx, afile_name, aimage s = Size( aimage ); h = LonArr( 8 ); h[0] = '59A66A95'xL; // 956AA659 h[1] = s[1]; h[2] = s[2]; h[3] = 64; h[4] = Long(s[1]) * s[2] * 8L; h[5] = 96; h[6] = 0; h[7] = 0; arch = Sys_Byte_Order(); if ( 'LSB' EQ arch ) then ByteOrder, h, /HTONL OpenW, fd, afile_name, /get_lun WriteU, fd, h; if ( 'LSB' EQ arch ) then ByteOrder, h, /NTOHL block_size = 512; block = FltArr( s[1] * 2, block_size ); idx_re = IndGen( h[1] ) * 2 idx_im = idx_re + 1; line = FltArr( 2 * h[1] ); block_idx = 0L; mod_block_idx = 0L; for y = 0L, s[2]-1 do begin line[idx_re] = Float( aimage[*,y] ); line[idx_im] = Imaginary( aimage[*,y] ); mod_block_idx = block_idx mod block_size; block[ *, mod_block_idx ] = line; if ( mod_block_idx EQ (block_size-1) ) then begin WriteU, fd, block; endif block_idx = Temporary( block_idx ) + 1; endfor ;// write remaining data in block: if ( (mod_block_idx NE 0 ) AND $ (mod_block_idx NE (block_size-1)) ) then begin WriteU, fd, block[*,0:mod_block_idx]; endif Close, fd Free_Lun, fd end

7.11.8 WRITE_DCPLX ;// ************************************************************************** ;// FILE : write_dcplx.pro


;// ;// ;// ;// ;// ;// ;// ;// ;//


-------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : write double complex extended sun raster format -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: write_dcplx.pro,v 1.2 2007/05/03 21:33:52 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro write_dcplx, afile_name, aimage s = Size( aimage ); h = LonArr( 8 ); h[0] = '59A66A95'xL; // 956AA659 h[1] = s[1]; h[2] = s[2]; h[3] = 128; h[4] = Long(s[1]) * s[2] * 8L; h[5] = 95; h[6] = 0; h[7] = 0; arch = Sys_Byte_Order(); if ( 'LSB' EQ arch ) then ByteOrder, h, /HTONL OpenW, fd, afile_name, /GET_LUN WriteU, fd, h; if ( 'LSB' EQ arch ) then ByteOrder, h, /NTOHL block_size = 512; block = DblArr( s[1] * 2, block_size ); idx_re = indgen( h[1] ) * 2 idx_im = idx_re + 1; line = DblArr( 2 * h[1] ); block_idx = 0L; mod_block_idx = 0L; for y = 0L, s[2]-1 do begin line[idx_re] = Float(aimage[*,y]) line[idx_im] = Imaginary(aimage[*,y]) mod_block_idx = block_idx mod block_size; block[ *, mod_block_idx ] = line; if ( mod_block_idx EQ (block_size-1) ) then begin WriteU, fd, block; endif block_idx = Temporary( block_idx ) + 1; endfor ;// write remaining data in block: if ( (mod_block_idx NE 0 ) AND $ (mod_block_idx NE (block_size-1)) ) then begin WriteU, fd, block[*,0:mod_block_idx]; endif Close, fd Free_Lun, fd end

7.12 READ ROUTINES 7.12.1 READ_BYTE ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_byte.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster file (8 bit unsigned char) --------------------------------------------------------------------------


;// ;// ;// ;//


PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_byte.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro read_byte, afile_name, aimage Get_Lun, fd OpenR, fd, afile_name h = LonArr( 8 ); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL; end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_byte: unhandled header magic number: ", Z)', h[0]; Return; end; endcase; aimage = BytArr( h[1], h[2] ); ReadU, fd, aimage; Close, fd; Free_Lun, fd; end

7.12.2 READ_INT16 ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_int16.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster format (short int) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_int16.pro,v 1.2 2007/05/03 21:35:52 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// byteorder, aimage, /HTONL ;// ************************************************************************** pro read_int16, afile_name, aimage Get_Lun, fd; OpenR, fd, afile_name; h = LonArr( 8 ); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_int16: unhandled header magic number: ", Z)', h[0] Return; end; endcase; aimage = IntArr( h[1], h[2] ); ReadU, fd, aimage; Close, fd; Free_Lun, fd; end



7.12.3 READ_INT32 ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_int32.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster format (int - 32 bit) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_int32.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// byteorder, aimage, /HTONL ;// ************************************************************************** pro read_int32, afile_name, aimage Get_Lun, fd; OpenR, fd, afile_name; h = LonArr(8); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL; end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_int32: unhandled header magic number: ", Z)', h[0] end; endcase; aimage = LonArr( h[1], h[2] ); ReadU, fd, aimage; Close, fd; Free_Lun, fd; end

7.12.4 READ_FLT ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_flt.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster format (float) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_flt.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// byteorder, aimage, /FTOXDR ;// ************************************************************************** pro read_flt, afile_name, aimage Get_Lun, fd; OpenR, fd, afile_name; h = LonArr( 8 ); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_flt: unhandled header magic number: ", Z)', h[0]; Return; end; endcase;



aimage = FltArr( h[1], h[2] ); ReadU, fd, aimage; Close, fd; Free_Lun, fd; end

7.12.5 READ_DBL ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_dbl.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster file (double) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_dbl.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// byteorder, aimage, /FTOXDR ;// ************************************************************************** pro read_dbl, afile_name, aimage Get_Lun, fd; OpenR, fd, afile_name; h = LonArr( 8 ); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL; end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_dbl: unhandled header magic number: ", Z)', h[0]; Return; end; endcase; aimage = DblArr( h[1], h[2] ); ReadU, fd, aimage; Close, fd; Free_Lun, fd; end

7.12.6 READ_SCPLX ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_scplx.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster file (short int complex) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_scplx.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// ************************************************************************** pro read_scplx, afile_name, aimage Get_Lun, fd; OpenR, fd, afile_name; h = LonArr( 8 ); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL; end



'59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_scplx: unhandled header magic number: ", Z)', h[0] Return; end; endcase; aimage = IntArr( 2 * h[1], h[2] ); ReadU, fd, aimage; idx = IndGen( h[1] ) * 2 aimage = Complex( aimage[idx,*], aimage[idx+1,*] ); Close, fd; Free_Lun, fd; end

7.12.7 READ_FCPLX ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_fcplx.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster file (float complex) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_fcplx.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// ************************************************************************** ;// byteorder, aimage, /FTOXDR ;// ************************************************************************** pro read_fcplx, afile_name, aimage Get_Lun, fd OpenR, fd, afile_name h = LonArr( 8 ) ReadU, fd, h case h[0] of '956AA659'xL : begin; // LSB system byteorder, h, /HTONL end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_fcplx: unhandled header magic number: ", Z)', h[0] Return; end; endcase; aimage = ComplexArr( h[1], h[2] ); ReadU, fd, aimage Close, fd Free_Lun, fd end

7.12.8 READ_DCPLX ;// ;// ;// ;// ;// ;// ;// ;// ;// ;// ;//

************************************************************************** FILE : read_dcplx.pro -------------------------------------------------------------------------AUTHOR : Nico Adam -------------------------------------------------------------------------CONTENT : read extended sun raster file (double complex) -------------------------------------------------------------------------PROJECT : Terrafirma Process Validation -------------------------------------------------------------------------VERSION : $Id: read_dcplx.pro,v 1.1 2007/05/03 20:45:40 nadam Exp $ **************************************************************************

;// **************************************************************************



;// byteorder, aimage, /FTOXDR ;// ************************************************************************** pro read_dcplx, afile_name, aimage Get_Lun, fd; Openr, fd, afile_name; h = LonArr( 8 ); ReadU, fd, h; case h[0] of '956AA659'xL : begin; // LSB system ByteOrder, h, /HTONL; end '59A66A95'xL : begin; // MSB system ;// nothing to do end else: begin Print, FORMAT='("read_dcplx: unhandled header magic number: ", Z)', h[0] Return; end; endcase; aimage = ComplexArr( h[1], h[2] ); ReadU, fd, aimage; Close, fd; Free_Lun, fd; end

-- End of document --