AIRSAR Data Processor Version 6.38:  5/25/2003 

Version 6.38 :   5/25/2003

  Problem description:

    For the processor version control,  we implemented  three processor related version numbers. 
    This  includes the original processor software version number, which will remain unchanged for
    backward  compatibility, and the addition of two version numbers: the Calibration Version
    and the Post-processing  Version. 

  Format of  the Calibration Version and the Post-processing Version:

    These two new version fields are appended to the end of the New Header (the first record of
    the output  file).
    The formats of the Calibration Version Field and the Reprocessing Version Field are described
    in the following sections.

I)  Calibration Version Field

Calibration version field should include the following:
1.    The year that the data were acquired followed by a letter to indicate different campaigns during
        the  same year that  might have required different calibration files.  For example, in 2001, we
        had  three  separate campaigns throughout the year.  These 3 campaigns would be labeled
        as 2001A, 2001B, and 2001C respectively.
2.    A character field representing the antenna calibration version.  Version A would be the baseline
       antenna pattern file  used  while calibrating the Rosamond data.  Version B could indicate a
        new antenna pattern that was implemented at a later date.
3.    A character field representing the absolute gain calibration version.  Version A would be the
       RECAL file derived while calibrating the Rosamond corner reflector data.
4.    A character field representing changes in the parameters stored in the SENSOR file.
5.    A character field representing the relative phase calibration version.  Similarly, version A would
       be the INTF file derived  while calibrating the Rosamond corner reflector data.
6.    Future calibration parameters such as absolute height bias may be included by adding
       characters to the Calibration version field.

This version field is right-justified to be consistent with other entries in the New Header.  An example
of  the 50-character Calibration Version field is shown here:

CALIBRATION VERSION =                   2001A.ABCD

In this example, the data were collected in the first 2001 campaign, the antenna pattern was the
original  version A, the RECAL file was updated to version B, the SENSOR file was updated to version
C whereas the INTF file was updated to version D.  For POLSAR jobs, the INTF file version field does
not apply.   However, we should still reserve that character field for INTF file to be consistent with
TOPSAR jobs. There are 10 extra character fields available for future calibration updates.

If we implement this Calibration Version field in the header, the processor will have to be modified to
write out this field in the new header with the data acquisition year and the version.
Examples:1). AAAA if nothing has been updated
                   2). BAAA indicates applying a modified antenna pattern to correct the CV POLSAR
                        imagery radiometric calibration anomaly (CHV and CVV) which described in 
                        version 6.36

II) Post-processing Version Field

This field should include the post-processing date followed by a letter indicating the type of post-
processing  performed.  The lookup table for post-processing types should be catalogued by the
year of data acquisition.  This means that for each year of data acquisition, we could have up to 26
different types of post-processing.  Here is an example:

POST-PROCESSING VERSION =          30JAN2002.2001A.F

This file was last reprocessed on 30 January, 2002 with post-processing type F where this is the 6th
problem encountered for data collected in 2001A.  The version entry is right-justified.  The AIPT
processor will have to be modified to write out this field with N/A as shown below:

POST-PROCESSING VERSION =                                      N/A
___________________________________________________________________

AIRSAR Data Processor Version 6.37:  12/20/2002

Version 6.37 : 12/20/2002

   Problem description:

   For the (slant-range imagery) POLSAR mode data sets the algorithm used in previous processor
   versions  to generate the corner coordinates used the aircraft location with an estimated offset. 
   The coordinates   generated with this algorithm were not always accurate and were not consistent
    with the method used to generate the corner coordinates for TOPSAR data sets.

    Remedy:

For the POLSAR mode this version now uses the processing reference track peg-point (latitude, longitude and heading) to compute the ground location of the corner of the image.  The coordinates generated in this way are more accurate than those generated using the previous method and are consistent with those generated for the TOPSAR data sets.  See Figure 1.3 of the Data Format Document:  http://airsar.jpl.nasa.gov/data/data_format.pdf   for a depiction of the peg-point coordinates.

The parameter header (defined in the Data Format Document) has been modified in the following way:  Fields 14-17 have been updated with values using the new algorithm, and Fields 99 and 100 now report the correct along-track (S0) and cross-track (C0) offsets for first sample of the image.

Note:  This version does NOT include the CV channel radiometric correction incorporated into version 6.36 of the processor.  A future version will include both the present (6.37) upgrade and the CV channel radiometric correction.

___________________________________________________________________

AIRSAR Data Processor Version 6.36:  06/05/2002

Version 6.36 : 06/05/2002

   Problem   Description :

CV Channel radiometric calibration anomaly in POLSAR mode

We observed in the CV POLSAR imagery (CHV and CVV) since 1998, there was a 2.5 dB dip in magnitude around 42º look angle.  By comparing CHH and CVV magnitude imagery as a function of range, the difference plot resembles the ringing effect due to multipath or poor termination.  We performed a number of flight tests and isolated the problem to the POLSAR antenna itself.  We also re-examined POLSAR data collected in 1996 over a very uniform tropical forest in Brunei and observed the same effect, but at a much smaller level (less than 1 dB). So this appears to be an antenna pattern calibration issue.

Remedy:  

An IDL procedure was written (cvv_cal) to compensate for this antenna pattern anomaly.  It reads in the C-band compressed Stokes matrix file, applies the correction curve (based on a reference data set) to the CHV and CVV channels, and writes the corrected data out to disk with the updated processor version number (6.36).

________________________________________________________________

AIRSAR Data Processor Version 6.35:  02/15/2002

Version 6.35 : 02/15/2002

  Problem description:

Image intensity error of the TOPSAR data in   the new Phase Unwrapping program with a bug from the version 6.34.  The bug was a ramp function applied on the image intensity data.

  Remedy:

To remove  the ramp function from the intensity data.

_______________________________________________________________

AIRSAR Data Processor Version 6.34:  02/04/2002

Version 6.34 : 02/04/2002

  Problem Description :

Enhancing of Phase unwrapping function and a bug corrected is updated in this version 6.34 .

   I)     Phase unwrapping enhancement :

The new phase unwrapping program will bootstrap the next patch interferometric data  for the phase unwrapping efficiency.    Filtering   the interferogram phase function is added as well.

   II)   Bug correction in the parameter header :

Three fields of the parameter header were corrupted due to the mis-allocation of the memory under certain circumstances.   The corrupted  annotations in the parameter header were Site_name, Image_title, and   Frequency_ label.

   This annotation anomaly did not affect the image quality at all.

Remedy:

The  upgraded phase unwrapping with bootstrapping and filtering functions is on line .

The memory mapping of the header code was updated and corrected to correct Site_name, Image_title, and  Frequency_ label in the parameter header .

________________________________________________________________

AIRSAR Data Processor Version 6.33:  08/27/2001

Version 6.33 : 08/27/2001

  Problem description:

The ENVI3.4/IDL software package from a third party can't read the length of Radiometric Correction Vectors beyond 19600 bytes(2450 samples*8).

So the Radiometric Correction Vectors will be truncated to 19600 bytes until ENVI fixes the bug.  Many AIRSAR investigators use  ENVI to analyze their data.  Most TOPSAR data will not be  affected since the ground projected images has fewer samples than the truncated correction vector.

  Remedy :

For version 6.33, the integrated processor generates three extra files to contain the full size of each Radiometric Correction Vectors as cmxxxx_c.rad_vec , cmxxxx_l.rad_vec, and cmxxxx_p.rad_vec.   

In the mean time, a README file is also generated as shown below.

RADIOMETRIC CORRECTION VECTORS ( ASCII format):

         Column 1: for the HH channel

         Column 2: for the HV channel

         Column 3: for the VV channel

Each column of the above channel has a full size data as the same as range line size.   The file names of each frequency are  cmxxxx_c.rad_vec, cmxxxx_l. rad_vec , and cmxxxx_p.rad_vec.

Note:  ENVI 3.4  can NOT read the size of Radiometric Correction Vectors of the AIRSAR Header beyond 19600 bytes. The maximum size of that is 24080.   So, the Radiometric Correction Vectors of the AIRSAR   Header contains only upto 19600 bytes for this version.  ENVI 3.5/IDL 5.5 will fix this problems claimed by the company then the AIRSAR header length will  go back to normal case.

________________________________________________________________

AIRSAR Data Processor Version 6.32 : 06/25/2001 

Version 6.32 : 06/25/2001

  Problem Description:

The Radiometric Correction Vector in the AIRSAR header had been generated with a constant shorter length (10240 sampels).

  Remedy:

In version 6.32 the processor generates the full size of the radiometric correction vectors based on the number of range samples in each image file (up  to 2560 samples instead of 1280 samples). 

_______________________________________________________________

AIRSAR Data Processor Version 6.31 : 04/25/2001   

Version 6.31 : 4/25/2001

  Problem Description:

There was an error in the calibration of the 40 MHz polarimetric L-band and P-band data which led to a mis-registration between C-band data and L/P-band datain both XTI1/XTI1P and POLSAR 40 MHz data .

  Remedy:  

Both POLSAR and XTI1 data are being re-processed and re-delivered to investigators for the affected data sets.