Various doc fixes

Author: CPBridge

docs/ann.rst

@@ -33,7 +33,7 @@ contains. The required metadata elements include:
 * A ``number`` (``int``), an integer number for the group.
 * A ``label`` (``str``) giving a human-readable label for the group.
 * A ``uid`` (``str`` or :class:`highdicom.UID`) uniquely identifying the group.
-  Usually, you will want to generate UID for this.
+  Usually, you will want to generate a UID for this.
 * An ``annotated_property_category`` and ``annotated_property_type``
   (:class:`highdicom.sr.CodedConcept`) coded values (see :ref:`coding`)
   describing the category and specific structure that has been annotated.
@@ -338,8 +338,8 @@ all measurements in the group, but you can also filter for measurements matching
 a certain name.
 
 Measurements are returned as a tuple of ``(names, values, units)``, where
-``names`` is a list of nnames as :class:`highdicom.sr.CondedConcept` objects,
-``units`` is a list of units also as :class:`highdicom.sr.CondedConcept`
+``names`` is a list of names as :class:`highdicom.sr.CodedConcept` objects,
+``units`` is a list of units also as :class:`highdicom.sr.CodedConcept`
 objects, and the values is a ``numpy.ndarray`` of values of shape (*N* by *M*)
 where *N* is the number of annotations and *M* is the number of measurements.
 This return format is intended to facilitate the loading of measurements into

docs/image.rst

@@ -64,8 +64,8 @@ frames of the image:
   array with minimal processing. The raw bytes are decompressed if necessary
   and reshaped to form the frame of the correct shape, but no further pixel
   transforms are applied. These are referred to as "stored values" within the
-  DICOM standard. Note that the pydicom `.pixel_array` property returns stored
-  values for all frames at once.
+  DICOM standard. Note that the pydicom ``.pixel_array`` property returns
+  stored values for all frames at once.
 * :meth:`highdicom.Image.get_frame()`: In addition to the above, this method
   applies pixel transforms stored in the file to the stored values before
   returning them. The transforms applied are configurable through parameters

docs/pixel_transforms.rst

@@ -108,7 +108,7 @@ specifies which should be used. By default, the first item is used. Values for
   following standard Python indexing convention.
 * A ``str`` used to match the ``"LUTLabel"`` attribute, which is a free-text
   human readable string identifying the LUT, to select the map.
-* A ``pydicom.sr.coding.Code`` or ``highdicom.sr.coding.CodedConcept`` used to
+* A ``pydicom.sr.coding.Code`` or :class:`highdicom.sr.CodedConcept` used to
   match the code describing the units of the LUT (contained in the
   ``"MeasurementUnitsCodeSequence"`` attribute). See :doc:`coding` for more
   information on using codes.

docs/seg.rst

@@ -561,17 +561,17 @@ pixels in the original source DICOM image.
 `Highdicom` supports such cases in two ways. The first, possible when the
 segmentation array is defined on a regularly-sampled 3D grid, is to pass the
 segmentation array as an instance of the :class:`highdicom.Volume` class
-instead of a plain NumPy array. (see :doc:`volume` for an overview of volumes).
-Since the :class:`highdicom.Volume` class specifies its position within the
-frame of reference coordinate system, the position of each plane can be
-inferred automatically. The volume can have an arbitrary size, spacing, and
-orientation and these properties do not need to match those of the source
-images. Just like a standard NumPy array, the volume can be either in the
-"label map" form, where each pixel values specifies segment membership, or
-"stacked segment" form, with a further array dimension along which binary
-segments are stacked. In the "label map" case the volume must have no channel
-dimensions. In the "stacked segments" case, the volume must have exactly one
-channel dimension with the descriptor being the "SegmentNumber" tag.
+instead of a plain NumPy array (see :doc:`volume` for an overview). Since the
+:class:`highdicom.Volume` class specifies its position within the frame of
+reference coordinate system, the position of each plane can be inferred
+automatically. The volume can have an arbitrary size, spacing, and orientation
+and these properties do not need to match those of the source images. Just like
+a standard NumPy array, the volume can be either in the "label map" form, where
+each pixel values specifies segment membership, or "stacked segment" form, with
+a further array dimension along which binary segments are stacked. In the
+"label map" case the volume must have no channel dimensions. In the "stacked
+segments" case, the volume must have exactly one channel dimension with the
+descriptor being the "SegmentNumber" tag.
 
 .. code-block:: python
 
@@ -1506,7 +1506,7 @@ If the segmentation is defined on a regularly-sampled 3D grid (possibly with
 omittted frames, tiled frames, and/or multiple segments), the
 :meth:`highdicom.seg.Segmentation.get_volume()` method may be used to create a
 :class:`highdicom.Volume` from its frames. The options we have already seen
-(``segment_numbers``, combine_segments``, ``relabel``, ``rescale_fractional``)
+(``segment_numbers``, ``combine_segments``, ``relabel``, ``rescale_fractional``)
 are also available here.
 
 .. code-block:: python

src/highdicom/frame.py

@@ -59,7 +59,7 @@ def encode_frame(
         ``"JPEG2000Lossless"`` transfer syntaxes with color images, the pixel
         data must be passed in in RGB format and will be converted and stored
         as ``"YBR_FULL_422"`` (``"JPEGBaseline8Bit"``), ``"YBR_ICT"``
-        (``"JPEG2000"``), or `"YBR_RCT"`` (``"JPEG2000Lossless"``). In these
+        (``"JPEG2000"``), or ``"YBR_RCT"`` (``"JPEG2000Lossless"``). In these
         cases the values of photometric metric passed must match those given
         above.
     pixel_representation: Union[highdicom.PixelRepresentationValues, int, None], optional
@@ -78,19 +78,19 @@ def encode_frame(
     Raises
     ------
     ValueError
-        When `transfer_syntax_uid` is not supported or when
-        `planar_configuration` is missing in case of a color image frame.
+        When ``transfer_syntax_uid`` is not supported or when
+        ``planar_configuration`` is missing in case of a color image frame.
 
     Note
     ----
-    In case of color image frames, the `photometric_interpretation` parameter
+    In case of color image frames, the ``photometric_interpretation`` parameter
     describes the color space of the **encoded** pixel data and data may be
     converted from RGB color space into the specified color space upon
     encoding.  For example, the JPEG codec converts pixels from RGB into
     YBR color space prior to compression to take advantage of the correlation
     between RGB color bands and improve compression efficiency. Therefore,
-    pixels are supposed to be provided via `array` in RGB color space, but
-    `photometric_interpretation` needs to specify a YBR color space.
+    pixels are supposed to be provided via ``array`` in RGB color space, but
+    ``photometric_interpretation``` needs to specify a YBR color space.
 
     """  # noqa: E501
     rows = array.shape[0]