Opticks is an open source remote sensing platform.

• Imagery and video analysis
• Zoom, pan, rotate spatially large datasets
• Layer GIS features, annotations, results, and other information over your data to provide context
• Many image display controls such as colormap, histogram and transparency
• Support for datasets larger than four gigabytes
• Combine steps using graphical wizards
• Support for processing data in its native interleave of BIP, BSQ or BIL
• Add new capabilities via extension

• NITF 2.0/2.1
• GeoTIFF
• ENVI
• ASPAM/PAR
• CGM
• DTED
• RAW
• JPEG
• GIF
• PNG
• BMP
• ESRI Shapefile
• HDF5
• AVI
• MPEG

Please see the PlugIn Developer and Core Developer wiki pages for more information.

The repository structure follows a few rules:

• Releases are initially made as a release candidate (rc1) for a testing period before a final release is made.
• The main devlopment branch is master and represents the current, most volatile development line. It's for all new features big and small. Major and minor (first and second digit) releases are made from this branch. (4.12.0, 5.0.0, etc.) Only certain developers have commit access to master. If you have a bug fix or feature, you need to create an appropriate branch or fork the repo and make a pull request.
• support/* branches are for less volative development and features. Features and fixes which don't break the ABI should do here first and then get moved to master if they are applicable for the next major release. Minor (third digit) releases are made from these branches. (4.12.1, etc.)
• hotfix/* branches are for emergency hot fixes which occur during testing. These result in additional release candidates. (rc2, rc3, etc.) Once a final release is made, bug fixes should go in the support/* branches.
• feature/* and bugfix/* branches are for large features slated for the next release or future releases. The difference between the two is purely for convenience and a bug can be fixed in a feature/* branch if you'd prefer. This is a convenient way to develop a large feature or collaboratively develop a feature. If you're not sure if a feature should go right into master or support/, or if it should get a feature/ branch, create one of these, branching is cheap.
• Include Fixes # messages and links to issues when committing to branches so they are easy to track. These don't need to be in every commit message, just the final one for a branch.

NOTE: You may see some odities in the commit history, tags, etc. since this repository was originally imported from subversion with a fairly complex branch structure.