Owl Processing Guide

The Owl thermal hyperspectral sensor is new to the arsf and so new problems may occur during processing. Please add any new issues to the bottom of this wiki. Details on the Owl sensor are available ​here and information on Owl testing is available ​here.

Owl Pre-Processing Checks

Before processing, or as part of unpacking, the following checks are recommended:

1) Check for dark frames. From the top level directory run:

grep -rnw thermal/owl/*/capture/*.hdr -e "autodarkstartline"

Data cannot be processed without this keyword, so ensure that it is listed for each flightline. If dark frames are missing they can be added following instructions in the Dark Frames section.

2) Check for nav synchronisation:

grep -rnw thermal/owl/*/capture/*.hdr -e "GPS"

If there are no GPS times in the data header, the data cannot be geocorrected. Add timestamps from corresponding Fenix flightlines or estimate from the logsheet or file creation time.

3) Check for calibration data:

ls thermal/owl/*/capture/T1* ls thermal/owl/*/capture/T2*

Make sure that there is at least 1 T1 and 1 T2 file present for the flight and that it is located in the same directory as the flight data. If there are double the number of expected flightlines, then the calibration data is probably stored in separate directories from the flight data. It will need moving to be processed. e.g. if line 1 only has T1 and T2 files and line 2 has data, but no T1 and T2, move/copy line 1 data into line2.

4) Check for dropped frames in the .log files. If there are more than a few note on the ticket. Make sure the log file is in the same layout as 2014 288 before starting processing.

5) Check the files and directories are correctly named.

File Naming

Our scripts require that data be named according to the standard convention e.g. OWL219b-14-1, where 219 is the julian day, b the sortie, 14 the year and 1 the flightline. The files should have been renamed during unpacking, but if this is not the case, run proj_tidy.sh -e -p <project directory> to generate the move commands. Check that every move command is present before executing, as partial renaming cannot be completed in a second run. Taking a backup of the data files is recommended before renaming.

Dark Frames

The radiometric calibration will fail if the dark frames are saved in a separate file to the data (Ops sometimes do this). Check the capture directory for any extra files labelled like they might be dark frames and append them to the end of the data file. Remember to add the autodarkstartline key to the header file. Alternatively use the script stitchOwl.py.

e.g. stitchOwl.py -c .../thermal/owl/OWL241a-15-8

Specim's calibration tool actually only uses dark frames to detect blinkers; it does not use them to radiometrically calibrate the data. Therefore, if dark frames are completely missing a calibration file (e.g. T1) may be used instead.

Radiometric Calibration

Specim have provided a tool to process the Owl raw data into calibrated data. Details on using this tool are located ​here if required.

To batch process the data use: processOWL.py -p <project directory>

To process individual lines use: process_OWL_line.py -p <project directory> -f <flightline>

Each flightline should have it's own calibration data in the form of additional files prefixed T1 and T2 in the capture directory. If these are not present the script will produce a warning. Run the script again with the option -c auto once the submitted flightlines have produced the required calibration files (Check the log has passed the "Writing calibration file..." step), or manually specify a calibration file with -c <flightline with calibration data_calibration.rad>.

All output files are written to the flight line subdirectory of /processing/owl/flightlines/level1b and logs written to /processing/owl/logfiles. The output files consist of the data (*_proc.bil) and if not specified as inputs, the calibration (*_calibration.rad) and blinker files (*blinkers.dat), each with their own header file. During processing a symlink appears in the output flight line folder to prevent simultaneous processing over the same line. You may need to remove this if processing is aborted before it is automatically removed.

Files named as tp3f35cf3d_7182_4f17_8294_425fa4dc2953.raw are temporary files and will be removed on completion. If they remain check the logs for errors. No autodark found means the files need to be appended with dark frames.

Blinking Pixels/Vertical Stripes

During the radiometric calibration blinking pixels are tested for and removed from the data. It is likely that the default settings will not remove all the blinking pixels and the data will have vertical stripes. To remove these reprocess with a lower value of pixstabi e.g.

process_OWL_line.py -p <project directory> -f <flightline> -m pixstabi=0.005

The pixstabi modifier defines the standard deviation of the time series allowed for a normal pixel, so reducing this removes more pixels above this range. It is not expected that all blinking pixels can be removed as the blinking pixel routine does not yet appear to be optimal. Do not make the value too low as this will remove too many pixels and result in thick vertical stripes where the data has been replaced. It will also remove a considerable amount of spectral information, so check that the spectra still look reasonable. Somewhere between the first 2 images below is desirable.

Level 1b Owl data (2014 238) calibrated with different values of pixstabi (default 0.011, 0.005, 0.003, 0.0025, 0.002)

Dropped Frames

If there are dropped frames they should be recorded in a .log file in the capture directory. Make sure they appear in the level 1b data file as empty lines before geocorrection to map the flight line correctly.

Geocorrection

Create a dem in exactly the same way as for fenix. This should be saved in the processing/hyperspectral/dem directory, not the owl directories, so only 1 copy is required. e.g. from the project directory type create_apl_dem.py --aster.

Geocorrection is conducted in the same way as for fenix data, using APL. Generate a config file using generate_apl_config.py -o processing/owl/o2014219b.cfg (make sure it begins with an o) to keep processing separate from fenix. You may need to add the boresight values to the config file ( e.g. owl_boresight = 0.12 -0.32 0.32). You may also want to delete or set to false the fenix lines if only processing owl data. Make sure the project directory structure is complete (same as fenix). Submit to the grid using specim_qsub.py <config_file> and calculate the SCTs. Once you have done this you can generate the mapped data (102 bands) by setting owl_bandlist = ALL and setting the SCT value for each line.

Early owl files have corrupt nav files, so if you get this message in the log or 'Requested sync time index is out of bounds in GetSyncDelay()' set the config file to use_nav = false.

If there appears to be striping across the mapped files, bright and dark lines, or sections of a flight line don't match up the sensor has probably dropped frames. These can be checked in the .log file in the capture directory. These empty lines need to be inserted into the level 1b data file before geocorrection to map the flight line correctly.

Create mask files

Specim's tool produces a blinker file locating each of the blinking pixels. This are auomatically converted to mask files by APL, but can also be converted using the script blinker2mask.py. Make sure mask files are present before making a delivery so the files can be correctly moved into the delivery directory.

Making a delivery

Use the make_arsf_delivery.py script, specifying owl as the sensor type:

make_arsf_delivery.py --projectlocation <project directory> --deliverytype owl --final

Readme =

There is no separate owl option for make a readme. Generate a config file for the Fenix and manually edit it for the Owl. If you just edit the tex file you will have to run autoqc on the command line, but if there are no overflows and underflows just remove the table from the readme and state it in a sentence instead.

Checking

Follow the Fenix delivery checking procedure.

Also check that detector response is stable across the entire flight by examining the calibration (.rad) files (These are also bil files). If there are dramatic changes in the calibration curves for a particular flight line, make sure that it is not used to calibrate a different flight line. You will also need to double check that the data processed for that flight line look correctly calibrated.

Problems

There are likely to be problems with this newly developed processing chain. Please add problems (and solutions!) below and they will be fixed in due course.

• The boresight needs entering into the config file / needs adding to table. Should not be a problem for project processing as we will always have a boresight.
• Bad pixels remain - will eventually look into a masking routine &/ get a better blinker detection routine from Specim.
• Calibration files saved separately to data will not be processed - asm is working on fixing this as part of the new unpacking scripts.