Merge conflict

docs/concepts/Camera Geometry and Projections/Camera Geometry.md → docs/concepts/camera-geometry-and-projections/camera-geometry.md

@@ -28,7 +28,7 @@ though it does not require radiometric calibration).
       - **Longitude Direction = East** Longitude values increase to the
         east
 
-Definitions for the geometric reference terms can be found in [Learning About Map Projections](../Camera%20Geometry%20and%20Projections/Learning%20About%20Map%20Projections.md)
+Definitions for the geometric reference terms can be found in [Learning About Map Projections](../camera-geometry-and-projections/learning-about-map-projections.md)
 
 
 ## Camera Information Applications 
@@ -175,7 +175,7 @@ Enceladus. In this example, **phocube** will generate a 6-band output
 cube.
 
 @TODO
-!!! Note "The image used in this example has been processed through Level1 \[ingestion, spiceinit and radiometric calibration\]. Refer to: [Working with Cassini ISS Data](Camera%20Geometry.md)"
+!!! Note "The image used in this example has been processed through Level1 \[ingestion, spiceinit and radiometric calibration\]. Refer to: [Working with Cassini ISS Data](camera-geometry.md)"
 
 Each band will contain the information asked for (parameters set to
 true) in the following command:

docs/concepts/control-networks/automatic-registration.md

+
+# Automatic Registration
+
+## Introduction
+
+Automatic registration is the attempt to match a pattern in an image
+cube. Pattern matching has many different purposes.
+
+Examples:
+
+1.  Register an entire image to a second image. The registration of an
+    image is performed by moving (rubber-sheet) the pixels to output
+    pixel locations that result in pattern matching directly to a second
+    'fixed' or 'truth' image.
+
+    - Use: [coreg](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/coreg/coreg.html)
+
+2.  Relative cartographic registration between a number of overlapping
+    images. Pattern matching is used to build a control point network
+    across a number of overlapping images for solving and adjusting the
+    camera pointing that are then applied to map project the images.
+
+    - Use: [pointreg](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/pointreg/pointreg.html) or [jigsaw](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/jigsaw/jigsaw.html)
+
+3.  Find and record the pixel location(s) of a camera reference mark
+    (e.g., Vidicon reseau mark) across an image
+
+    - Use: [findrx](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/findrx/findrx.html)
+
+
+## Match Algorithm Definition Files (PVL)
+
+Registration of images can be an advanced and complicated process. ISIS3
+is designed to supply a choice of match/registration algorithms to
+handle a variety of image data conditions. An ISIS3 "plugin" algorithm
+expects all match algorithms to supply parameter information through a
+Parameter Value Language (PVL) definition file. Examples of match
+algorithm PVL's can be found in
+
+    $ISIS3DATA/base/templates/autoreg/coreg*.def 
+
+Registration applications (such as coreg) will allow the user to choose
+from this collection of PVL files in the user interface gui.
+
+A PVL file can be generated for a selected match algorithm with 
+[autoregtemplate](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/autoregtemplate/autoregtemplate.html).
+
+## Match Algorithms
+
+### Maximum Correlation
+
+The Maximum Correlation match algorithm is most commonly used. The
+algorithm computes a  
+correlation coefficient that will range from no correlation (zero) to
+perfect correlation (one).
+
+Example templates for Maximum Correlation can be found in:
+
+ 
+    $ISIS3DATA/base/templates/autoreg/coreg.maxcor.p*.s*.def.  
+
+
+An example PVL for the Maximum Correlation follows:
+
+    Object = AutoRegistration
+    
+      Group = Algorithm
+        Name = MaximumCorrelation
+        Tolerance = 0.7
+      End_Group
+    
+    End_Object
+
+!!! tip
+
+    A successful correlation is met if the **Goodness of Fit** is **Greater Than** 
+    the Tolerance parameter value for the Maximum Correlation Algorithm.
+
+### Minimum Difference
+
+The Minimum Difference match algorithm performs a subtraction of the
+Pattern Chip and the sub-region of the Search Chip. The **Goodness of 
+Fit** will range from zero for a perfect match, while larger values 
+indicate a less likely match. The **Goodness of Fit** is measured as an 
+absolute value and will never be negative.
+
+Example templates for Minimum Difference can be found in:
+
+    $ISIS3DATA/base/templates/autoreg/coreg.mindif.p*.s*.def.
+
+An example PVL for the Minimum Difference follows:
+
+    Object = AutoRegistration
+    
+      Group = Algorithm
+        Name = MinimumDifference
+        Tolerance = 100
+      End_Group
+    
+    End_Object
+
+!!! tip
+
+    A successful correlation is met if the **Goodness of Fit** is **Less
+    Than** the Tolerance parameter value for the Minimum Difference Algorithm.
+
+## Tolerance
+
+The Tolerance parameter is used by both Maximum
+Correlation and Minimum
+Difference. Each correlation coefficient result
+(**Goodness of Fit**) is tested against the Tolerance. Tolerance is set
+within the PVL file along with the chosen
+registration algorithm.
+
+Points that fail the Tolerance test are reported by the autoreg
+applications as:
+
+- `FitChipToleranceNotMet`
+
+- `SurfaceModelToleranceNotMet`
+
+## Chips
+
+There are two chips used in automatic registration, the Pattern
+Chip and the Search Chip. The
+two chips are nothing more than sub-areas of the input image cubes,
+generally small in size. An NxM Chip is defined to be an N-Sample by
+M-Line region of an image. Basic elements of a chip are:
+
+  - N and M are natural numbers (1, 2, 3...,50)
+  - Like image cubes, chip coordinates are sample/line and 1-band based
+  - The center of the chips is (N - 1)/2 + 1 and (M - 1)/2 + 1
+
+### Pattern Chip
+
+A Pattern Chip will contain the data you would like to match. This
+Pattern Chip is basically extracted from the 'Reference' image (it is
+also referred to as the 'Truth' image). The Pattern Chip is then walked
+across the Search Chip that has been extracted from
+the other image that is to be modified.
+
+The PVL for a Pattern Chip defined as 25 Samples x 25 Lines (625 pixels)
+is:
+
+    Object = AutoRegistration
+    
+      Group = PatternChip
+        Samples = 25
+        Lines = 25
+      End_Group
+    
+    End_Object
+
+**Pattern Chip Size Requirement:**
+
+N + M \>= 3. This ensures that the pattern is not a single pixel.
+
+???+ tip "Tips"
+
+    1.  The feature to match included in the Pattern Chip does not have to
+        be in the center.
+    2.  The more "bland" the data is within the input images, the larger the
+        Pattern Chip box should be. A larger box will allow for more pixel
+        DN variance.
+    3.  In general, avoid very small box sizes less than 11 Samples X 11
+        Lines
+    4.  The smaller the size of the Pattern Chip, the greater the chance of
+        matching too many areas in the search chip and returning a 'false
+        positive' match.
+
+### Search Chip
+
+A Search Chip is the sub-area of the image cube that the pattern might
+be found in. The Pattern Chip is walked through the
+Search Chip looking for the best match. The Search Chip must be larger
+than the Pattern Chip (at least one pixel bigger on line/sample size).
+
+The PVL for a Search Chip defined as 45 Samples x 45 Lines (2025 pixels)
+is:
+
+    Object = AutoRegistration
+    
+      Group = PatternChip
+        Samples = 25
+        Lines = 25
+      End_Group
+    
+      Group = SearchChip
+        Samples = 45
+        Lines = 45
+      End_Group
+    
+    End_Object
+
+**Search Chip Size Requirement:**
+
+!!! danger "TODO - Update Link"
+
+    TODO: Update **Sub-Pixel Definition** links to new docs once those pages are migrated.
+
+N(search) \>= N(pattern) + 2 and similarly for M. This ensures that the
+Pattern Chip spans at least a 3x3 window within the Search Chip. An
+important requirement for surface fitting in order to compute sub-pixel
+accuracy. (Refer to: [Sub-Pixel Definition](https://DOI-USGS.github.io/ISIS3/gh-pages/ISIS_Cube_Format)).
+
+???+ tip "Tips"
+
+    - The Search Chip must be larger than the Pattern Chip (at least one
+        pixel bigger on line/sample size).
+    - The Search Chip needs to be large enough to allow a 'best guess' or
+        predicted line and sample mis-registration offset between the images
+        that are to be correlated.  
+        - **SearchChipSize = PatternChipSize + (OffsetPixelEstimate *
+            2)**
+    - BUT, the Search Chip shouldn't be too much larger than the Pattern
+        Chip.  
+        - The difference in size could greatly affect how long the
+            registration application would run.
+    - Refer to PVL example above:
+        - An estimated offset between two input images of 10 Lines by 10
+            Samples will need a Search Chip size (10 Line offset * 2) by
+            (10 Sample offset * 2). The Search Chip size in this example
+            needs to be at least 20*20 Lines/Samples bigger than the pattern
+            chip.
+        - PatternChipSize = 25 * 25
+        - SearchLineDimention = 25 + (10 * 2) = 45 * SearchSampleDimention = 25 + (10 * 2) = 45
+        - SearchChipSize= 45 * 45
+
+## Restricting Input Pixel Ranges
+
+!!! danger "TODO - Update Link"
+
+    TODO: Update **Input Pixels** and **Special Pixel** links to new docs once those pages are migrated.
+
+The validity of the [input pixels](https://DOI-USGS.github.io/ISIS3/gh-pages/ISIS_Cube_Format) 
+of the Pattern Chip is the very first test
+performed. Prior to the match algorithm being invoked during the walk
+process, a simple test is performed to ensure there are enough pixels to
+work with. Pixels are deemed valid if they are in the minimum/maximum
+range and/or they are not [special pixel](https://DOI-USGS.github.io/ISIS3/gh-pages/Special_Pixels.html) values.
+
+The Pattern Chip is only checked once. If it does not contain enough
+valid pixels, the match is deemed to fail. Otherwise, the walk through
+occurs and the sub-area is extracted from the Search
+Chip. If this sub-area does not have enough valid
+pixels a match will be deemed to fail at that search location.
+
+Points that fail the default or specified Valid Minimum/Maximum and/or
+ValidPercent tests are reported by the autoreg applications as:
+
+- `PatternNotEnoughValidData`
+
+- `FitChipNoData`
+
+- `SurfaceModelToleranceNotMet`
+
+### Valid Minimum/Maximum
+
+Input image pixels (DN) values may be excluded from the match
+algorithm if they fall outside of a specific range. The ranges can be
+specified independently for the Search Chip and Pattern Chip. While this
+might not be necessary for a successful registration, excluding pixel
+data could improve the chances depending on the characteristics of the
+input images. (i.e., Eliminating the DN range of deep shadow areas in an
+image).
+
+The ranges are handled via the PVL as follows:
+
+    Object = AutoRegistration
+    
+      Group = PatternChip
+        Samples = 20
+        Lines = 20
+        ValidMinimum = 0.1
+        ValidMaximum = 0.4
+      End_Group
+    
+      Group = SearchChip
+        Samples = 55
+        Lines = 55
+        ValidMinimum = 2.5
+        ValidMaximum = 10.5
+      End_Group
+    
+    End_Group
+
+### Valid Pixel Count (ValidPercent)
+
+`ValidPercent` defines the percentage of valid data that is required
+within the Pattern Chip or Search Chip. The parameter can be set in
+conjunction with Valid Minimum/Maximum.
+
+The Valid Percent would be handled via the PVL as follows:
+
+    Object = AutoRegistration
+    
+      Group = PatternChip
+        Samples = 20
+        Lines = 20
+        ValidPercent = 80
+      End_Group 
+    End_Group
+
+Default for `ValidPercent`: `AutoRegDefaults`
+
+!!! tip
+
+    `ValidPercent` is specified in the Pattern Chip, as the sub-area 
+    chip of the search area will use the same value.
+
+## Fit Chip
+
+As the Pattern Chip walks through the sub-regions
+of the Search Chip , a third chip is generated
+called a Fit Chip. The Fit Chip will have the same line and sample
+dimensions as the Search Chip. The Fit Chip is filled with the resulting
+**Goodness of Fit** values at every position that the Pattern Chip is walked
+across the Search Chip computing a fit correlation value.
+
+The highest or lowest **Goodness of Fit** values within the Fit Chip
+generally represent the position that best matched between the Pattern
+and Search areas. It is only good to a maximum of **ONE pixel accuracy**.
+
+The Fit Chip can be interactively generated and viewed using the image
+display application  
+[qnet](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/qnet/qnet.html).
+
+
+## Sub-Pixel Accuracy
+
+!!! danger "TODO - Update Link"
+
+    TODO: Update **Sub-Pixel Definition** links to new docs once those pages are migrated.
+
+The attempt to reach a registration of sub-pixel accuracy is performed
+on the Fit Chip. The Fit Chip is created as the
+Pattern Chip is walked through Search
+Chip. The Fit Chip contains the resulting
+correlation position between the two chips of a maximum of ONE pixel
+accuracy. In many cases, the actual, ultimate registration may lie
+somewhere between two pixels. (Refer to:
+[Sub-Pixel Definition](https://DOI-USGS.github.io/ISIS3/gh-pages/ISIS_Cube_Format)).
+
+The sub-pixel accuracy can be turned off through the PVL settings as
+follows:
+
+    Group = Algorithm
+      Name = MaximumCorrelation
+      SubPixelAccuracy = False
+    End_Group
+
+When the sub-pixel accuracy is turned off, the whole pixel with the best
+fit is returned.  
+Default for SubPixelAccuracy: AutoRegDefaults
+
+!!! tip
+
+    By default, if an ideal **Goodness of Fit** is found (e.g. Zero (0.0) for
+    Minimum Difference or One (1.0) for Maximum Correlation), we have a perfect 
+    fit and assume that it is the best position. In this case, the sub-pixel 
+    accuracy phase is omitted.
+
+### Surface Modeling
+
+A continuous mathematical surface is modeled based on the data within
+the Fit Chip. A 2nd degree 2-dimensional
+polynomial is calculated given an NxN window of points extracted from
+the Fit Chip surrounding the correlation peak (highest value)-which
+represents the whole pixel registration. An estimate of the true
+sub-pixel registration position of the chip can be reached based on this
+surface model.
+
+A perfect 3D linear fit (global maximum) would be represented by a
+spherical surface with a single high peak.
+
+## AutoRegDefaults
+
+(As of May 20, 2009)
+
+    ValidPercent                  = 50.0
+    MinimumZScore                 = 1.0
+    Tolerance                     = Null (no default)
+    ReductionFactor               = 1.0
+    
+    SubPixelAccuracy              = True
+    SurfaceModelDistanceTolerance = 1.5
+    SurfaceModelWindows           = 5
+    SurfaceModelEccentricityRatio = 2 (2:1)

docs/concepts/control-networks/image-registration.md

+
+# Image Registration
+
+There two alternative paths to automatically creating a tie-point
+control network.
+
+1.  **Autoseed Path**
+      - This path will distribute and establish tie-points based on
+        polygon overlaps of a collection of images.
+      - The image coordinates for each point are immediately measured
+        with the **autoseed** application.
+      - The **footprintinit** and **findimageoverlaps** are required by
+        **autoseed**
+1.  **Seedgrid Path**
+      - A gridded pattern of tie-points are established based on
+        specified latitude/longitude values and spacing.
+      - The image coordinates for each "seeded" point are measured with
+        the **cnetadd** application.
+
+## Creating a Tie-Point Control Network
+
+| autoseed Path     | seedgrid Path |
+| ----------------- | ------------- |
+| spiceinit         | spiceinit     |
+| footprintinit     |               |
+| findimageoverlaps | seedgrid      |
+| autoseed          | cnetadd       |
+| cnetref           | cnetref       |
+| pointreg          | pointreg      |
+
+## Related ISIS3 Applications
+
+[**spiceinit**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/spiceinit/spiceinit.html)  
+[**footprintinit**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/footprintinit/footprintinit.html)  
+[**findimageoverlaps**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/findimageoverlaps/findimageoverlaps.html)  
+[**autoseed**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/autoseed/autoseed.html)  
+[**seedgrid**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/seedgrid/seedgrid.html)  
+[**cnetadd**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/cnetadd/cnetadd.html)  
+[**cnetref**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/cnetref/cnetref.html)  
+[**pointreg**](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/pointreg/pointreg.html)

docs/concepts/control-networks/multi-instrument-registration.md

+
+# Multi-Instrument Registration
+
+## Reasons for merging datasets
+
+List of useful reasons:
+
+  - Change detection
+  - Spatial / Spectral merges
+  - Understanding instrument calibration (optical distortion,
+    radiometric similarities)
+  - Multivariate statistical analysis
+  - Principal component analysis
+  - Etc., etc., etc.
+
+## Choosing the "truth"
+
+Datasets from different instruments often do not register using the raw,
+native pointing. In order to merge these datasets, they must be brought
+together by selecting one dataset as having the correct pointing or
+“truth”. The pointing for the other datasets is then adjusted to match
+the truth.
+
+Choosing the truth is dependent on the datasets being merged. First, the
+data with the known best pointing could be chosen, such as the Mars
+Global Surveyor’s MOLA. Or if simply merging HiRISE and CTX, HiRISE
+pointing is considered to be more accurate than CTX pointing.
+
+The differing resolution of the datasets is something to keep in mind.
+You will not want to attempt to register HiRISE directly to MOLA as the
+difference in resolution is too large to find a common point. In
+general, you will want to build up in resolution.
+
+
+| Resolution: | Lowest | -      | -      | -      | -   | Highest |
+| ----------  |:------:|:------:|:------:|:------:|:---:|:-------:|
+| Dataset:    | MOLA   | MOC WA | Themis | MOC NA | CTX | HiRISE  |
+
+Registering to MOLA can be difficult. Using a shaded relief version of
+MOLA (program – **shade**), and running either
+[map2map](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/map2map/map2map.html)
+or
+[map2cam](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/map2cam/map2cam.html)
+to bring MOLA into the local ground area will help.
+
+| CTX                                                                          | MOLA                                                                         |
+| ---------------------------------------------------------------------------- | -----------------------------------------------------------------------------|
+| ![CTX High Res](../../assets/control-networks/ctx-high-res.png){ width=200 } | ![MOLA Low Res](../../assets/control-networks/mola-low-res.png){ width=200 } |
+
+### Registration Tools
+
+[**deltack**](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/deltack/deltack.html)
+
+  - Updates camera pointing for a single image
+  - Tie one image to another
+  - THEMIS to MOLA, HiRISE to MOC NA, HiRISE to CTX, etc.
+
+[**jigsaw**](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/jigsaw/jigsaw.html)
+
+  - Simultaneously updates camera pointing for multiple images
+  - Typically used for regional or global mosaics
+
+### Initial Datasets
+
+Start with Experiment Data Records (EDRs) if possible to ensure
+consistency among the datasets for SPICE and mapping parameters such as
+planetocentric vs planetographic and positive longitude east vs west.
+
+## Merging THEMIS / CTX / HiRISE (controlled to MOLA)
+
+### Controlling THEMIS to MOLA
+
+Start with the lowest resolution dataset, which in this case is THEMIS.
+Pick a matching point between THEMIS and MOLA using qview. (Hint: It is
+easier to use a crater as a match point.)  
+Write down the latitude / longitude of the point on MOLA and the sample
+/ line of the point on the THEMIS image. Update the THEMIS pointing by
+running the ISIS3 program `deltack`.
+
+    deltack from=themis.cub lat1=molaLat lon1=molaLon samp1=themisSamp line1=themisLine
+
+This will update the themis pointing to the MOLA.
+
+### Controlling CTX to THEMIS
+
+Next, control the CTX image to the THEMIS image by picking a match point
+the same as was done between the MOLA and THEMIS. Use the THEMIS image
+that has the updated pointing (after
+[deltack](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/deltack/deltack.html)).
+
+    deltack from=ctx.cub lat1=themisLat lon1=themisLon samp1=ctxSamp line1=ctxLine
+
+### Controlling HiRISE to CTX
+
+![](../../assets/control-networks/ctx-hirise-blink.gif){ align=right width=350 }
+
+[Image: CTX/HiRISE Misregistration. Errors: ~40 samples, ~20 lines]
+
+First, control the HiRISE red ccds locally by running the ISIS3 program,
+[autoseed](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/autoseed/autoseed.html), 
+which will automatically pick match points among the red ccd’s. Then run the ISIS3 program,
+[pointreg](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/pointreg/pointreg.html), 
+which will sub-pixel register the points that autoseed picked.
+
+Next, pick a matching point between HiRISE RED5 and the CTX image with
+the updated pointing (after deltack). Record the CTX latitude /
+longitude and the red5 sample / line. This will be used as a ground
+point when running jigsaw on the red CCDs to adjust the pointing.  
+In order to use this point as a ground point, the radius is needed. Run
+the ISIS3 program,
+[campt](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/campt/campt.html)
+to get this radius.
+
+    campt from=ctx.cub lat=cxtLat lon=ctxLon type=ground
+
+This ground point can now be added to the control net file that was
+output from pointreg using any editor.
+
+    Object              = ControlPoint
+       PointType        = Ground
+       PointId          = Ground_1
+       Latitude         = -5.3320739040534
+       Longitude        = 213.71209674872
+       Radius           = 3394090.9408245
+    
+       Group            = ControlMeasure
+         SerialNumber   = MRO/HIRISE/RED5/848376111:51904/2
+         MeasureType    = Automatic
+         Sample         = 1131.92
+         Line           = 18555.3
+         ErrorLine      = 0
+         ErrorSample    = 0
+         ErrorMagnitude = 0
+         DateTime       = 2007-05-25T09:24:50
+         ChooserName    = "TLS"
+         GoodnessOfFit  = 0
+         Reference      = True
+       End_Group
+     End_Object
+
+Finally, run
+[jigsaw](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/jigsaw/jigsaw.html)
+on the HiRISE red cubes.
+
+See Also:
+
+  - controlled mosaics
+  - [jigsaw](https://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/jigsaw/jigsaw.html)
+
+| MOC Registered with HiRISE Red CCDs                     | MOC Registered with HiRISE Red CCDs (zoomed)                     |
+| ------------------------------------------------------- | ---------------------------------------------------------------- |
+| ![](../../assets/control-networks/moc-hirise-blink.gif) | ![](../../assets/control-networks/moc-hirise-zoomedin-blink.gif) |
+
+## Projecting all
+
+Project the THEMIS, CTX and HiRISE red images using the CTX resolution
+and latitude/longitude range.
+
+    cam2map from=ctx.cub to=ctx.equi.cub pixres=mpp resolution=5.0 
+      map=$base/templates/maps/equirectangular.map
+    
+    cam2map from=themis.cub to=themis.equi.cub map=ctx.equi.cub pixres=map defaultrange=map
+    
+    /bin/ls *RED* | sed s/.balance.cub// > red.lis
+    
+    cam2map from=\$1.balance.cub to=\$1.equi.cub map=ctx.equi.cub pixres=map defaultrange=map
+      -batch=res.lis
+    
+    /bin/ls *RED*.equi.cub > redEqui.lis
+    
+    automos fromlist=redEqui.lis mosaic=redMos.cub match=no
+
+More Information: [Learning About Map Projections](../camera-geometry-and-projections/learning-about-map-projections.md)
+
+## Problems and Issues
+
+  - Registering to MOLA can be difficult:
+    
+      - Use shaded relief if possible ([shade](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/shade/shade.html))
+      - Use
+        [map2cam](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/map2cam/map2cam.html)
+        or
+        [map2map](http://isis.astrogeology.usgs.gov/Application/presentation/Tabbed/map2map/map2map.html)
+        to bring MOLA image into local ground area to help with the
+        smaller MOLA image size
+
+  - Simultaneous CTX and HiRISE observations do not register
+    
+      - Inconsistent sample/line offsets
+      - Probably have timing issues
+      - Maybe some boresight misalignment
+      - Will research this problem as more CTX data becomes available
+
+  - MOC Narrow Angle does not align with HiRISE or CTX
+    
+      - Update the MOC NA focal length
+      - MOC NA camera model has no distortion model
+      - More research needed in this area
+
+  - MRO CRISM
+    
+      - Unable to fully decipher the PDS IMAGE_PROJECTION_OBJECT
+      - No CRISM camera model in ISIS3
+      - Unable to compare HiRISE, MOC, and THEMIS to CRISM
+
+## Images on this page
+
+[mola-low-res.png](../../assets/control-networks/mola-low-res.png)
+(31.9 KB) Jesse Mapel,
+2016-05-31 02:59 PM 
+
+[ctx-high-res.png](../../assets/control-networks/ctx-high-res.png)
+(243 KB) Jesse Mapel,
+2016-05-31 02:59 PM 
+
+[ctx-hirise-blink.gif](../../assets/control-networks/ctx-hirise-blink.gif)
+(213 KB) Jesse Mapel,
+2016-05-31 03:06 PM 
+
+[moc-hirise-zoomedin-blink.gif](../../assets/control-networks/moc-hirise-zoomedin-blink.gif)
+(118 KB) Jesse Mapel,
+2016-05-31 03:12 PM 
+
+[moc-hirise-blink.gif](../../assets/control-networks/moc-hirise-blink.gif)
+(39.9 KB) Jesse Mapel,
+2016-05-31 03:12 PM 
\ No newline at end of file

docs/concepts/SPICE/SPICE Overview.md → docs/concepts/spice/spice-overview.md

@@ -33,7 +33,7 @@ processing will not be possible.
 
 At a minimum 'spiceinit' requires SpacecraftName, InstrumentId,
 TargetName, StartTime and StopTime. These keywords are loaded at the
-ingestion step ( [Importing Mission Data](../../getting-started/Using%20ISIS:%20First%20Steps/Locating%20and%20Ingesting%20Image%20Data.md) ).
+ingestion step ([Importing Mission Data](../../getting-started/using-isis-first-steps/locating-and-ingesting-image-data.md)).
 
 See also: [**Mission Specific
 Programs**](http://isis.astrogeology.usgs.gov/Application/index.html)