DOC: Fix typos in documentation

Found via `codespell -q 3 -S ./Modules/ThirdParty,./Documentation/ReleaseNotes`

Documentation/Download.md

@@ -67,7 +67,7 @@ Clone ITK using the commands
    $ cd ITK
 ```
 
-The latest stable release can be cloned into a local repositiory using
+The latest stable release can be cloned into a local repository using
 
 ```sh
    $ git clone -b release https://github.com/InsightSoftwareConsortium/ITK ITKLatestRelease

Documentation/Doxygen/ImageSimilarityMetrics.dox

@@ -30,7 +30,7 @@ particular problems.
 
 
 \subsection SimilarityMetrics Similarity Metrics
-Metrics are probably the most critical element of a registration problem. The metric defines what the goal of the process is, they measure how well the Target object is matched by the Reference object after the transform has been applied to it. The Metric should be selected in function of the types of objects to be registered and the expected kind of missalignment. Some metrics has a rather large capture region, which means that the optimizer will be able to find his way to a maximum even if the missalignment is high. Typicaly large capture regions are associated with low precision for the maximum. Other metrics can provide high precision for the final registration, but usually require to be initialized quite close to the optimal value.
+Metrics are probably the most critical element of a registration problem. The metric defines what the goal of the process is, they measure how well the Target object is matched by the Reference object after the transform has been applied to it. The Metric should be selected in function of the types of objects to be registered and the expected kind of missalignment. Some metrics has a rather large capture region, which means that the optimizer will be able to find his way to a maximum even if the missalignment is high. Typically large capture regions are associated with low precision for the maximum. Other metrics can provide high precision for the final registration, but usually require to be initialized quite close to the optimal value.
 
 Unfortunately there are no clear rules about how to select a metric, other that trying some of them in different conditions. In some cases could be and advantage to use a particular metric to get an initial approximation of the transformation, and then switch to another more sensitive metric to achieve better precision in the final result.
 

Documentation/Doxygen/Iterators.dox

@@ -289,7 +289,7 @@
 
   In general, iterators are not the kind of objects that users of the
   toolkit would need to use. They are rather designed to be used by
-  code developers that add new components to the toolkit, like writting
+  code developers that add new components to the toolkit, like writing
   a new Image filter, for example.
 
   Before starting to write code that use iterators, users should consider

Documentation/Doxygen/NeighborhoodIterators.dox

@@ -164,7 +164,7 @@ pixel in a neighborhood is always Size()/2.
 important.  SmartNeighborhoodIterator defines a special class of neighborhood
 iterators that transparently handle boundary conditions.  These iterators store
 a boundary condition object that is used to calculate a value of requested
-pixel indicies that lie outside the data set boundary.  New boundary condition
+pixel indices that lie outside the data set boundary.  New boundary condition
 objects can be defined by a user and plugged into SmartNeighboroodIterators as
 is appropriate for their algorithm.
 
@@ -230,7 +230,7 @@ for (regions_iterator++ ; regions_iterator != regions.end(); regions_iterator++)
 The NeighborhoodAlgorithm::ImageBoundaryFacesCalculator is a special function
 object that returns a list of sub-regions, or faces, of an image region.  The
 first region in the list corresponds to all the non-boundary pixels in the
-input image region.  Subseqent regions in the list represent all of the boundary
+input image region.  Subsequent regions in the list represent all of the boundary
 faces of the image (because an image region is defined only by a single index
 and size, no single composite boundary region is possible).  The list is
 traversed with an iterator.
@@ -244,7 +244,7 @@ iterators.
 
 \par 
 The best documentation of the API for these objects is are the class
-definitions themselves, since the API is subject to change as the tookit
+definitions themselves, since the API is subject to change as the toolkit
 matures and is refined.
 
 

Documentation/Doxygen/Registration.dox

@@ -33,12 +33,12 @@ elements. They are:
 
 \li \b Target: the object that is assumed to be static.
 \li \b Reference: the object that will be transformed in order to be superimpossed to the \e Target
-\li \b Transform: the mapping that will conver one point from the \e Reference object space to the \e Target object space.
+\li \b Transform: the mapping that will convert one point from the \e Reference object space to the \e Target object space.
 \li \b Metric: a measure that indicates how well the \e Target object matches the \e Reference object after transformation.
 \li \b Mapper: the particular technique used for interpolating values when objects are resampled through the \e Transform.
 \li \b Optimizer: the method used to find the \e Transform parameters that optimize the \e Metric.
 
-A particular registration method is defined by selecting specific implemementations of each one of these basic elements.
+A particular registration method is defined by selecting specific implementations of each one of these basic elements.
 In order to determine the registration method appropriated for a particular problem, is will be useful to answer the following questions:
 
 
@@ -68,7 +68,7 @@ This is a rapid description of the transforms implemented in the toolkit
 
 
 \subsection RegistrationMetrics Similarity Metrics
-Metrics are probably the most critical element of a registration problem. The metric defines what the goal of the process is, they measure how well the Target object is matched by the Reference object after the transform has been applied to it. The Metric should be selected in function of the types of objects to be registered and the expected kind of missalignment. Some metrics has a rather large capture region, which means that the optimizer will be able to find his way to a maximum even if the missalignment is high. Typicaly large capture regions are associated with low precision for the maximum. Other metrics can provide high precision for the final registration, but usually require to be initialized quite close to the optimal value.
+Metrics are probably the most critical element of a registration problem. The metric defines what the goal of the process is, they measure how well the Target object is matched by the Reference object after the transform has been applied to it. The Metric should be selected in function of the types of objects to be registered and the expected kind of missalignment. Some metrics has a rather large capture region, which means that the optimizer will be able to find his way to a maximum even if the missalignment is high. Typically large capture regions are associated with low precision for the maximum. Other metrics can provide high precision for the final registration, but usually require to be initialized quite close to the optimal value.
 
 Unfortunately there are no clear rules about how to select a metric, other that trying some of them in different conditions. In some cases could be and advantage to use a particular metric to get an initial approximation of the transformation, and then switch to another more sensitive metric to achieve better precision in the final result.
 
@@ -101,7 +101,7 @@ The following optimization methods are available:
 
 \section MultiResolutionRegistration Multiresolution
 
-The evaluation of a metric can be very expensive in computing time. An approach often used to improve performance is to register first reduced resolution versions of the target and reference objects. The resulting transform is used as the starting point for a second registration process performed in progresively higher resolution objects.
+The evaluation of a metric can be very expensive in computing time. An approach often used to improve performance is to register first reduced resolution versions of the target and reference objects. The resulting transform is used as the starting point for a second registration process performed in progressively higher resolution objects.
 
 It is usual to create first a sequence of reduced resolution version of the objects, this set of objects is called a <em> pryramid representation </em>. A Multiresolution method is basically a set of consecutive registration process, each one performed at a particular level of the pyramid, and using as initial transform the resulting transform of the previous process.
 

Documentation/Doxygen/Threading.dox

@@ -69,7 +69,7 @@
 
    Care must in taken in setting up an application to have separate
    application level (as opposed to filter level) execution threads.
-   Individual ITK objects are not guarenteed to be thread safe. By this
+   Individual ITK objects are not guaranteed to be thread safe. By this
    we mean that a single instance of an object should only be modified
    by a single execution thread.  You should not try to modify a single
    instance of an object in multiple execution threads.
@@ -80,7 +80,7 @@
    safety was chosen as a compromise between performance and flexibility.
    If we allow ITK objects to be modified in multiple threads then ITK
    would have to mutex every access to every instance variable of a 
-   class.  This would severly affect performance.
+   class.  This would severely affect performance.
 
    \section NumericsThreadSafety Thread Safety in the Numerics Library
 

Documentation/GitHelp.md

@@ -17,7 +17,7 @@ Additional information about [Git] may be obtained at these sites:
       * [PDF](github.com/downloads/nvie/gitflow/Git-branching-model.pdf) version.
     * [LearnGitBranching - Web application designed to help beginners grasp the powerful concepts behind branching](https://learngitbranching.js.org/)
   * Cheat sheets
-    * [Git sheat sheet](http://cheat.errtheblog.com/s/git)
+    * [Git cheat sheet](http://cheat.errtheblog.com/s/git)
     * [GitHub Git cheat sheet](https://services.github.com/on-demand/downloads/github-git-cheat-sheet/)
       * [PDF](https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf) version.
   * Git books

Documentation/ITK5MigrationGuide.md

@@ -57,9 +57,9 @@ are also now used in ITK. As a consequence, due to limitations in C++11 support
 Visual Studio 2013 (MSVC 12.0) and other older C++ complilers cannot be used to build ITK from 5.0 and forward.
 
 Errors similar to `error: conversion from 'int' to 'typename InterpolatorType::Pointer'` are a result of further
-type safty for dealing with pointers. Enhancements in nullptr behavior in ITKv5 provide more clear
+type safety for dealing with pointers. Enhancements in nullptr behavior in ITKv5 provide more clear
 type checking and respect the nullptr identifier.  The 'long 0' value
-known as NULL causes an abiguity for overload compilations of the ITKv5 smartpointers. To be backwards compatible
+known as NULL causes an ambiguity for overload compilations of the ITKv5 smartpointers. To be backwards compatible
 with pre C++11 compilers use the `ITK_NULLPTR` designation, otherwise replace NULL and 0 initialization of
 `itk::SmartPointer` with nullptr.
 
@@ -303,7 +303,7 @@ Spatial Objects Refactoring
 ---------------------------
 The SpatialObject classes were refactored to address issues and inconsistencies that had arisen over the years.  The severity of these issues and inconsistencies was such that the classes provided incorrect and/or unexpected behaviors that made their proper usage problematic.
 
-The most noteable change is that dependencies on VNL Tree data structures and the requirement that every SpatialObject be defined
+The most notable change is that dependencies on VNL Tree data structures and the requirement that every SpatialObject be defined
 in an object space were eliminated.   The VNL Tree data structures introduced unnecessary complexity, additional (redundant)
 transformations, and dependencies on VNL in the API that ITKv5 seeks to eliminate.   The elimination of a dependency on an IndexSpace
 simplified the set of transformations that each SpatialObject needed to maintain and made the API of every SpatialObject more consistent
@@ -354,7 +354,7 @@ As implied above, the changes to SpatialObject are extensive.   They include the
 * `RemoveChild()` and `RemoveAllChildren()` fixed to remove all pointers to / from those children to / from the tree
 * Helper functions simplify the specification of `IsInsideInObjectSpace()`, `ValueAtInObjectSpace()`, and other computations that potentially traverse an SO tree.
 * Derived classes typically only need to implement `IsInsideInObjectSpace()` and `ComputeMyBoundingBoxInObjectSpace()` member functions. Logic for `ValueAtInObjectSpace()`, `IsInsideInWorldSpace()` and such is improved.
-* PointBasedSpatialObjects had a PointListType type declaration.  This was confusing because it refered to a list of SpatialObjectPoints and not ITK::Points.  So, to avoid such confusion, now TubeSpatialObjects define TubePointListType, BlobSpatialObjects define BlobPointListType, and so forth.
+* PointBasedSpatialObjects had a PointListType type declaration.  This was confusing because it referred to a list of SpatialObjectPoints and not ITK::Points.  So, to avoid such confusion, now TubeSpatialObjects define TubePointListType, BlobSpatialObjects define BlobPointListType, and so forth.
 * `ImageMaskSpatialObject::GetAxisAlignedBoundingBoxRegion()` was removed. `ImageMaskSpatialObject::ComputeMyBoundingBoxInIndexSpace()` should be used instead.
 * `SpatialObjectReader::GetScene` was renamed to `GetGroup` along with changing the type from `ScenePointer` to `GroupPointer`.
   * Elements of a `Group` are now `Children`, so `scene->GetObjects` now becomes `group->GetChildren`
@@ -422,7 +422,7 @@ which return a `reverse_iterator`, compatible with the Standard C++ Library.
 `itk::StatisticsImageFilter`, `itk::LabelStatisticsImageFilter` and
 `itk::MinimumMaximumImageFilter` no longer produce an image as their
 primary output, as it was a shallow copy of the primary
-input. Additionally, minor API changes have occoured related to the
+input. Additionally, minor API changes have occurred related to the
 decorated output methods to conform to ITK conventions.
 
 `itk::NiftiImageIO` was changed to support different kinds of Analyze file conventions.

Documentation/Maintenance/Release.md

@@ -290,7 +290,7 @@ maintainers after an ITK Confab.
 
 ### Update the repository
 
-Use the commmand:
+Use the command:
 
 ```sh
    git checkout master
@@ -627,15 +627,15 @@ Finally, create symbolic link at `/projects/Insight/WWW/InsightDocuments/Web`.
 Update the ITK Software Guide
 -----------------------------
 
-The [ITK Sofware Guide] is available in both electronic and printed formats.
+The [ITK Software Guide] is available in both electronic and printed formats.
 Every time a new ITK version is released, the following steps must be taken to
 update the guide and make it available:
 
   * Add the necessary ITK contents (i.e. new modules, etc.).
   * Update the compiler and necessary tool (e.g. CMake minimum version)
     information if necessary.
   * Bump the ITK version in `Superbuild/External_ITK.cmake`.
-  * Set the `DRAFT_WATERMARK` CMake varable to `OFF` to remove the draft
+  * Set the `DRAFT_WATERMARK` CMake variable to `OFF` to remove the draft
     watermark.
   * Set the `PDF_QUALITY_LEVEL` CMake configuration option to `Screen` for the
     electronic version and `Printer` for the print version.
@@ -866,7 +866,7 @@ excellent packaging.
 [ITKPythonPackage]: https://itkpythonpackage.readthedocs.io/en/latest/index.html
 [ITK discussion]: https://discourse.itk.org/
 [ITK issue tracking]: https://issues.itk.org/
-[ITK Sofware Guide]: https://itk.org/ItkSoftwareGuide.pdf
+[ITK Software Guide]: https://itk.org/ItkSoftwareGuide.pdf
 [ITK wiki]: https://itk.org/Wiki/ITK
 [ITK Sphinx examples]: https://itk.org/ITKExamples/
 [releases page]: https://itk.org/Wiki/ITK/Releases

Documentation/UploadBinaryData.md

@@ -69,7 +69,7 @@ Once files have been uploaded to your account, they will be publicly available
 and accessible since data is content addressed. Specifically, the
 [hashsum_download] plugin in Girder looks through all public (or private if
 authenticated) data for files with the given hash. Thus, so as long as the file
-is publically available somewhere on [data.kitware.com], ITK will be able to
+is publicly available somewhere on [data.kitware.com], ITK will be able to
 retrieve the corresponding file.
 
 At release time, the release manager will upload and archive repository data