Skip to content

Commit df7606d

Browse files
luzpazdzenanz
authored andcommitted
DOC: Fix various typos in Documentation/ directory
1 parent a2bef9c commit df7606d

File tree

10 files changed

+16
-16
lines changed

10 files changed

+16
-16
lines changed

Documentation/Doxygen/Iterators.dox

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -140,7 +140,7 @@
140140
Another group of iterators support a moving neighborhood. Here the
141141
neighborhood can "iterate" over an image and a calculation can iterate
142142
over the neighborhood. This allows N-dimensional implementations of
143-
convolution and finite differences to be implemented succintly.
143+
convolution and finite differences to be implemented succinctly.
144144
This class of iterators is described in detail on the page
145145
\ref NeighborhoodIteratorsPage.
146146

Documentation/Doxygen/Modules.dox

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -609,7 +609,7 @@
609609
\defgroup Deprecated Deprecated Classes
610610

611611
Classes that are scheduled to be removed from the toolkit. Their
612-
funcionality is now provided by other classes or changes in the toolkit have
612+
functionality is now provided by other classes or changes in the toolkit have
613613
made them useless. Please report to their documentation and look in to their
614614
"Deprecated" section. This section should indicate what to do to replace
615615
this class in any affected code.

Documentation/Doxygen/Registration.dox

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ This is a rapid description of the transforms implemented in the toolkit
5858

5959
\li \b Rigid3D: This transform is specific for 3D, it supports only rotations and translations. Rotations are represented using \e Quaternions.
6060

61-
\li \b Rigid3DPerspective: A composition of a \e Rigid3D transform followed by a perpective projection. This transformation is intended to be used in applications like X-Rays projections.
61+
\li \b Rigid3DPerspective: A composition of a \e Rigid3D transform followed by a perspective projection. This transformation is intended to be used in applications like X-Rays projections.
6262

6363
\li \b Translation: A N-Dimensional translation internally represented as a vector.
6464

@@ -95,7 +95,7 @@ The following optimization methods are available:
9595

9696
\li <b> Amoeba </b>: Nelder Meade Downhill Simplex.
9797

98-
\li <b> One Plus One Evolutionary </b>: Stategy that simulates the biological evolution of a set of samples in the search space.
98+
\li <b> One Plus One Evolutionary </b>: Strategy that simulates the biological evolution of a set of samples in the search space.
9999

100100

101101

Documentation/docs/contributing/document_itk.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -142,5 +142,5 @@ and the second one being the title of the example in the
142142
#### Maintaining the documentation
143143

144144
The documentation is built nightly on the latest ITK commit, and deployed to GitHub pages
145-
at https://insightsoftwareconsortium.github.io/ITKDoxygen/, whose code is maintaned at
145+
at https://insightsoftwareconsortium.github.io/ITKDoxygen/, whose code is maintained at
146146
https://github.com/InsightSoftwareConsortium/ITKDoxygen.

Documentation/docs/learn/dicom.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ A question that is often asked is: I am trying to read/write a DICOM image,
66
but the pixel data has changed (the scalar range has changed from input file).
77

88
This surely comes from the fact that you did not used the proper
9-
pixel type to instanciate your reader. You have to consider:
9+
pixel type to instantiate your reader. You have to consider:
1010

1111
- `Bits Allocated`
1212
- `Bits Stored`
@@ -114,7 +114,7 @@ is however allowed that both files uses different transfer syntax uid
114114
(implicit/explicit, little/big endian). When a DICOM file is sent to a
115115
PACS, it is up to the implementor to decide what to do in case of
116116
duplicate `SOP Instance UID`. In most case you should expect that the
117-
image is not resent, as standard garantee this is already the same
117+
image is not resent, as standard guarantee this is already the same
118118
object.
119119

120120
> ⚠️ **Warning**

Documentation/docs/learn/faq.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,7 @@ possible to read/write 3D datasets as collections of 2D slices each one
6666
in an independent BMP, PNG or JPEG file by using the
6767
[`ImageSeriesReader`](https://itk.org/Doxygen/html/classitk_1_1ImageSeriesReader.html) and [`itk::ImageSeriesWriter`](https://itk.org/Doxygen/html/classitk_1_1ImageSeriesWriter.html).
6868

69-
‡ It is higly recommended not using this format. RAW is not a format, it
69+
‡ It is highly recommended not using this format. RAW is not a format, it
7070
is insufficient, inconsistent and simply dangerous. A RAW file without a
7171
header is useless, and once you add a header, it is not RAW anymore.
7272

@@ -158,7 +158,7 @@ GDCM is an open source package developed by the Creatis team at
158158
INSA-Lyon. It is distributed under a license similar to ITK: http://gdcm.sourceforge.net/Copyright.html.
159159

160160
GCDM uses CMake in order to configure its build process, so you will
161-
find a familiar setup. Once you download, configure and buid GDCM, you
161+
find a familiar setup. Once you download, configure and build GDCM, you
162162
can reconfigure ITK by running CMake in your ITK build, going into the
163163
advanced options and enabling `USE_GDCM`.
164164

@@ -461,7 +461,7 @@ the `Pixel Data` (`0x7fe0,0x0010`), thus it imply that the unused bits are
461461
**zeros**. In ITK, there is no such thing as 12-bit pixel type, thus
462462
when instanciating your reader you declare a 16-bit pixel type. This
463463
buffer is then passed back to GDCM which sees an array of 16bits values
464-
and then simply used the simpliest way to store this buffer back on
464+
and then simply used the simplest way to store this buffer back on
465465
disk: `Bits Stored = 16` and `High Bit = 15`. In case you have not made any
466466
change to your pixel buffer, implicitly the first 4 bits will be zero
467467
again. The only difference being that they are not as clearly declared

Documentation/docs/learn/fda_sw_development_guidelines.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -37,11 +37,11 @@ development of your application. That will included things like:
3737

3838
It is worth to point out that the software development process using in
3939
ITK and VTK are already following many of the FDA Guidelines for
40-
software developement. In particular
40+
software development. In particular
4141

4242
- Continuous Testing via Dashboard ([CTest](https://cmake.org/cmake/help/latest/manual/ctest.1.html))
4343
- Version control ([git](https://git-scm.com/))
44-
- Configuration standarization ([CMake](https://cmake.org/))
44+
- Configuration standardization ([CMake](https://cmake.org/))
4545
- Bug tracking ([GitHub](https://github.com/features/issues)/[GitLab issues](https://docs.gitlab.com/ee/user/project/issues/))
4646

4747
## General guidelines
@@ -57,5 +57,5 @@ medical devices you must look at the following documents:
5757
- [Guidance for the Submission of Premarket Notifications For Radionuclide Dose Calibrators - Guidance for Industry](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/guidance-submission-premarket-notifications-radionuclide-dose-calibrators-guidance-industry)
5858
- [Content of Premarket Submissions for Device Software Functions](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions)
5959

60-
These and other relevant documents can be found at the [FDA Guidance Doument search](https://www.fda.gov/regulatory-information/search-fda-guidance-documents)
60+
These and other relevant documents can be found at the [FDA Guidance Document search](https://www.fda.gov/regulatory-information/search-fda-guidance-documents)
6161
and the [Medical Devices and Radiation-Emitting Products Guidance Documents](https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/guidance-documents-medical-devices-and-radiation-emitting-products) sites.

Documentation/docs/migration_guides/itk_5_migration_guide.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -312,7 +312,7 @@ and intuitive.
312312
SpatialObjects now only have two spaces and two transforms directly associated with them:
313313
* ObjectSpace is the space that is "local" to each object. It is the physical space in which its data/parameters are defined. For
314314
example, for an ImageSpatialObject it is the "PhysicalSpace" (see Image Class definition) of the Image. For an Line/Tube/DTI and other
315-
point-based SpatialObjects, it is the inherent space in which the Point coordinates are specififed. Typically, when a SpatialObject is
315+
point-based SpatialObjects, it is the inherent space in which the Point coordinates are specified. Typically, when a SpatialObject is
316316
extracted from an Image, the parameters/coordinates of the SpatialObject are the space as the physical space of the source Image. Any
317317
children of a SpatialObject are defined within the ObjectSpace of that parent SpatialObject.
318318

Documentation/docs/migration_guides/itk_6_migration_guide.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -108,7 +108,7 @@ ITK versions, `PointSet::Clone()` did not copy any data. (It previously just
108108
created a default-constructed PointSet object, like `PointSet::CreateAnother()`
109109
does.)
110110

111-
For the sake of code readibility, a new `CoordinateType` alias is added for
111+
For the sake of code readability, a new `CoordinateType` alias is added for
112112
each nested `CoordRepType` alias. The old `CoordRepType` aliases will still be
113113
available with ITK 6.0, but it is recommended to use `CoordinateType` instead.
114114
The `CoordRepType` aliases will be removed when `ITK_FUTURE_LEGACY_REMOVE` is

Documentation/docs/scientific_ecosystem/itk_ecosystem.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ or sets of pipelines were:
3131
- [Praxix](https://code.google.com/archive/p/praxix/) was a collection
3232
of command line programs for image processing using ITK.
3333
- [ITK One Shot](https://github.com/daviddoria/ITK_OneShot) was a
34-
collecion of short programs to perform specific operations on images.
34+
collection of short programs to perform specific operations on images.
3535
- [ITKApps](https://github.com/InsightSoftwareConsortium/ITKApps) were
3636
a variety of applications written with ITK, ranging from simple uses
3737
of the toolkit to complex and GUI-based applications.

0 commit comments

Comments
 (0)