Changes between Initial Version and Version 1 of Procedures/OwlProcessing/OwlTool


Ignore:
Timestamp:
Nov 21, 2014, 3:48:59 PM (10 years ago)
Author:
lah
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Procedures/OwlProcessing/OwlTool

    v1 v1  
     1= Processing with the Owl Tool =
     2
     3The Owl Tool can be used directly from the command line to radiometrically calibrate raw Owl data, bypassing asrf scripts.  The most recent version of the tool may be copied from users/rsg/arsf/backups/owl_software/linux_versions and requires a Matlab Runtime Compiler to run (users/rsg/arsf/backups/owl_software/matlab_installer/).  Data is delivered in a specific folder structure, which must not be altered. Each flight line consists of a top level folder with a capture folder, a metadata folder and a manifest.xml file. The raw data is stored in the capture folder as an ENVI compatible pair of .raw and .hdr BIL files. There must also be calibration files prefixed T1 and T2 for the tool to process the data in the same folder, but these do not have to have the same name, so previous/following calibration files can be copied and used. The tool must be installed alongside the sensor.dat file, which contains sensor specific image sizing parameters. Further information is available in the provided instructions (users/rsg/lah/scratch_network/Owl_Public/Proctool_owl_user_instructions_v1.1.pdf). The tool is ran with the command below, with the 3 optional inputs set to empty strings:
     4
     5proctool_owl_2_6_2 <data input directory> '' '' ''
     6
     7This produces an output file pair of the same name as the input file with the extension _proc.dat. Blinker and calibration files are also produced if not specified on the command line. During processing temporary files are created in both the data input directory and the directory of the tool. All final output files are created in the same directory of the tool; there is no option to specify and output directory. Each flight line must therefore be processed individually, though a wrapper for batch processing may be developed in the future.
     8
     9= Known Problems =
     10 
     11 * If too many blinking pixels are identified too much of the data is replaced, causing v2.2 to crash and 2.6.2 to output no spectral content.
     12 * The tool is very slow.
     13 * We do not have the source code, so actual processing for each version is unknown.