Merge pull request #1040 from DimitriPapadopoulos/codespell

DOC: Typos found by codespell

Running [codespell](https://github.com/codespell-project/codespell) manually for now, but could be automated as suggested in systemd/systemd#15436 if there is interest.

Author: matthew-brett

Changelog

@@ -342,7 +342,7 @@ Bug fixes
   reviewed by PM)
 * Safer warning registry manipulation when checking for overflows (pr/753)
   (CM, reviewed by MB)
-* Correctly write .annot files with duplicate lables (pr/763) (Richard Nemec
+* Correctly write .annot files with duplicate labels (pr/763) (Richard Nemec
   with CM)
 
 Maintenance
@@ -997,7 +997,7 @@ visiting the URL::
 * Bugfix: Removed left-over print statement in extension code.
 * Bugfix: Prevent saving of bogus 'None.nii' images when the filename
   was previously assign, before calling NiftiImage.save() (Closes: #517920).
-* Bugfix: Extension length was to short for all `edata` whos length matches
+* Bugfix: Extension length was to short for all `edata` whose length matches
   n*16-8, for all integer n.
 
 0.20090205.1 (Thu, 5 Feb 2009)
@@ -1017,7 +1017,7 @@ visiting the URL::
   automatically dumped into this extension.
   Embedded meta data is not loaded automatically, since this has security
   implications, because code from the file header is actually executed.
-  The documentation explicitely mentions this risk.
+  The documentation explicitly mentions this risk.
 * Added :class:`~nifti.extensions.NiftiExtensions`. This is a container-like
   handler to access and manipulate NIfTI1 header extensions.
 * Exposed :class:`~nifti.image.MemMappedNiftiImage` in the root module.
@@ -1223,7 +1223,7 @@ visiting the URL::
 * Does not depend on libfslio anymore.
 * Up to seven-dimensional dataset are supported (as much as NIfTI can do).
 * The complete NIfTI header dataset is modifiable.
-* Most image properties are accessable via class attributes and accessor
+* Most image properties are accessible via class attributes and accessor
   methods.
 * Improved documentation (but still a long way to go).
 

doc/misc/pylintrc

@@ -79,7 +79,7 @@ output-format=colorized
 # Include message's id in output
 include-ids=yes
 
-# Tells wether to display a full report or only the messages
+# Tells whether to display a full report or only the messages
 reports=yes
 
 [MISCELLANEOUS]

doc/source/coordinate_systems.rst

@@ -530,7 +530,7 @@ then the image affine matrix $A$ is:
 
 Why the extra row of $[0, 0, 0, 1]$?  We need this row because we have
 rephrased the combination of rotations / zooms and translations as a
-transformation in *homogenous coordinates* (see `wikipedia homogenous
+transformation in *homogeneous coordinates* (see `wikipedia homogeneous
 coordinates`_).  This is a trick that allows us to put the translation part
 into the same matrix as the rotations / zooms, so that both translations and
 rotations / zooms can be applied by matrix multiplication.  In order to make

doc/source/devel/data_pkg_discuss.rst

@@ -369,7 +369,7 @@ Discovery
 
     Revsion ids could for example be hashes of the package instantiation
     (package contents), so they could be globally unique to the contents,
-    whereever the contents was when the identifier was made.  However, *tags*
+    wherever the contents was when the identifier was made.  However, *tags*
     are just names that someone has attached to a particular revsion id.  If
     there is more than one person providing versions of a particular package,
     there may not be agreement on the revsion that a particular tag is attached

doc/source/devel/devguide.rst

@@ -64,7 +64,7 @@ necessary and the branch gets tagged when a package version is released.
 Maintenance (as well as backport) releases or branches off from the respective
 packaging tag.
 
-There might be additonal branches for each developer, prefixed with intials.
+There might be additional branches for each developer, prefixed with initials.
 Alternatively, several GitHub (or elsewhere) clones might be used.
 
 
@@ -99,7 +99,7 @@ Changelog
 =========
 
 The changelog is located in the toplevel directory of the source tree in the
-`Changelog` file. The content of this file should be formated as restructured
+`Changelog` file. The content of this file should be formatted as restructured
 text to make it easy to put it into manual appendix and on the website.
 
 This changelog should neither replicate the VCS commit log nor the

doc/source/dicom/dicom_intro.rst

@@ -686,7 +686,7 @@ For example, there is a DIMSE service called "C-ECHO" that requests confirmation
 from the responding application that the echo message arrived.
 
 The definition of the DIMSE services specifies, for a particular DIMSE service,
-whether the DIMSE commend set should be followed by a data set.
+whether the DIMSE command set should be followed by a data set.
 
 In particular, the data set will be a full Information Object Definition's worth
 of data.

doc/source/dicom/dicom_mosaic.rst

@@ -124,7 +124,7 @@ Data scaling
 SPM gets the DICOM scaling, offset for the image ('RescaleSlope',
 'RescaleIntercept').  It writes these scalings into the nifti_ header.
 Then it writes the raw image data (unscaled) to disk.  Obviously these
-will have the corrent scalings applied when the nifti image is read again.
+will have the current scalings applied when the nifti image is read again.
 
 A comment in the code here says that the data are not scaled by the
 maximum amount.  I assume by this they mean that the DICOM scaling may

doc/source/dicom/dicom_orientation.rst

@@ -350,7 +350,7 @@ constant, to the voxel coordinate for the slice (the value for the slice
 index).
 
 Our DICOM might have the 'SliceLocation' field (0020,1041).
-'SliceLocation' seems to be proportianal to slice location, at least for
+'SliceLocation' seems to be proportional to slice location, at least for
 some GE and Philips DICOMs I was looking at.  But, there is a more
 reliable way (that doesn't depend on this field), and uses only the very
 standard 'ImageOrientationPatient' and 'ImagePositionPatient' fields.
@@ -385,7 +385,7 @@ unit change in the slice voxel coordinate.  So, the
 addition of two vectors $T^j = \mathbf{a} + \mathbf{b}$, where
 $\mathbf{a}$ is the position of the first voxel in some slice (here
 slice 1, therefore $\mathbf{a} = T^1$) and $\mathbf{b}$ is $d$ times the
-third colum of $A$.  Obviously $d$ can be negative or positive. This
+third column of $A$.  Obviously $d$ can be negative or positive. This
 leads to various ways of recovering something that is proportional to
 $d$ plus a constant.  The algorithm suggested in this `ITK post on
 ordering slices`_ - and the one used by SPM - is to take the inner

doc/source/dicom/siemens_csa.rst

@@ -124,7 +124,7 @@ Each item
 
 Now there's a different length check from CSA1.  ``item_len`` is given
 just by ``xx[1]``.  If ``item_len`` > ``csa_max_pos - csa_position``
-(the remaining bytes in the header), then we just read the remaning
+(the remaining bytes in the header), then we just read the remaining
 bytes in the header (as above) into ``value`` below, as uint8, move the
 filepointer to the next 4 byte boundary, and give up reading. 
 

doc/source/gettingstarted.rst

@@ -14,7 +14,7 @@ Getting Started
 ***************
 
 NiBabel supports an ever growing collection of neuroimaging file formats. Every
-file format format has its own features and pecularities that need to be taken
+file format format has its own features and peculiarities that need to be taken
 care of to get the most out of it. To this end, NiBabel offers both high-level
 format-independent access to neuroimages, as well as an API with various levels
 of format-specific access to all available information in a particular file
@@ -109,7 +109,7 @@ True
 
 In this case, we used the identity matrix as the affine transformation. The
 image header is initialized from the provided data array (i.e. shape, dtype)
-and all other values are set to resonable defaults.
+and all other values are set to reasonable defaults.
 
 Saving this new image to a file is trivial: