Redoss: The Next Generation!

• e.g. new_redoss merged/JD234/whatever.merged
• e.g. new_redoss merged/*/*.merged

The default behaviour is to create three types of imagery files: (1) plain ss, (2) beam pattern corrected ss, (3) rolling average beam pattern corrected ss. If any of these imagery files exist already and are newer than the .merged file, then the script will skip re-creating the imagery files. You can modify the default behaviour with the following switches.

-force: The default behaviour of the script is to skip files that have been previously converted (this is determined by the existence of a .ss, .ss_{bp,arc}, or .ss_{bp,arc}_rolling file).  You can use -force to force it to re-create them.
-pixel: Force a pixel size for ss creation, this value is passed to the new_redoss script.
-skip_plain: This will skip the creation of "plain" ss, this over-rides the -force option for this data type..
-skip_bp:  This will skip the creation of beam pattern corrected ss, this over-rides the -force option for this data type..
-skip_rolling:  This will skip the creation of rolling average beam pattern corrected ss, this over-rides the -force option for this data type.
-viewss:  This will pop up a viewing window to display the imagery data after it has been created
-DN_Shift:  Applies an intensity shift to imagery data (value is additive for reson systems, subtractive for simrad systems, default is 0)
-rolling:  Specify the number of pings to average for rolling beam pattern corrections (default is 500)

For Reson systems only:
-snippet | -sidescan | -ri_theta:  Specify the data type 

A few rules, caveats, and features:

1. It auto-generates the ss directory and required subdirectories to match the input path.
2. It expects the file extensions to be .merged. If this is not the case, have a peek at the script and you should be able to figure out what to change.
3. It expects merged data to be in the 'merged' directory, all lowercase.
4. You can use command line wildcards, e.g. new_redoss merged/JD1{22,23,24}/*.merged
5. If anything major pukes in the script, it reports errors to a file named 'error.log' in the project directory. Have a look at this file after a big batch job to make sure nothing funky happened. In the event of a single faulty line, it'll write out to the error log and skip to the next line.

Download a copy for Simrad systems here.
Download a copy for Reson systems here.