Fix typos (#1954)

Signed-off-by: Dimitris Apostolou <[email protected]>

Author: rex4539

CONTRIBUTING.md

@@ -192,7 +192,7 @@ remains linear, avoiding the "bubbles" characteristic of the
 [GitFlow](https://www.endoflineblog.com/gitflow-considered-harmful)
 workflow.
 
-### Use the Fork, Luke.
+### Use the Fork, Luke
 
 In a typical workflow, you should **fork** the OpenEXR repository to
 your account. This creates a copy of the repository under your user
@@ -214,7 +214,7 @@ [email protected] mail list.
 
 Contributions should be submitted as GitHub pull requests. See
 [Creating a pull request](https://help.github.com/articles/creating-a-pull-request/)
-if you're unfamiliar with this concept. 
+if you're unfamiliar with this concept.
 
 The development cycle for a code change should follow this protocol:
 
@@ -336,7 +336,7 @@ code.
 
 * Function return types go on a separate line:
 
-        const float &	
+        const float &
         Header::pixelAspectRatio () const
         {
             ...
@@ -452,7 +452,7 @@ each version with three numbers: ``major.minor.patch``, where:
 
 * ``major`` - indicates incompatible API changes
 * ``minor`` - indicates functionality added in a backwards-compatible manner
-* ``patch`` - indicates backwards-compatible bug fixes 
+* ``patch`` - indicates backwards-compatible bug fixes
 
 ## Contributing to the Website
 
@@ -474,7 +474,7 @@ Building the website requires that ``sphinx``, ``breathe``, and
 ``doxygen`` are installed. It further requires the [sphinx-press-theme]
 (https://pypi.org/project/sphinx-press-theme). Complete dependencies
 are described in the [requirements.txt](website/requirements.txtg)
-file. 
+file.
 
 On Debian/Ubuntu Linux:
 
@@ -498,7 +498,7 @@ browser to preview the resulting website, that is, load
 ``file://<build-directory>/website/sphinx/index.html`` into your web
 browser.
 
-Once you submit a PR, a check labled ``docs/readthedocs.org:openexr``
+Once you submit a PR, a check labeled ``docs/readthedocs.org:openexr``
 will validate the build. Click on the ``Details`` link to
 preview. Also, a link to this preview will be added automatically to
 the PR description.
@@ -550,11 +550,11 @@ The preferred workflow is:
 
    c. Increment ``OPENEXR_VERSION_PATCH`` in
       [src/lib/OpenEXRCore/openexr_version.h](src/lib/OpenEXRCore/openexr_version.h)
-   
+
    d. Update the ``IMATH_TAG`` setting in
       [cmake/OpenEXRSetup.cmake](cmake/OpenEXRSetup.cmake) to
       correspond to the proper Imath release.
-   
+
    e. Add release notes to [CHANGES.md](CHANGES.md):
 
       - Generate a list of links to merged pull requests.
@@ -589,16 +589,16 @@ The preferred workflow is:
 
       - If there are any public CVE's, mention them explicitly with a
         link to the CVE registry item.
-      
+
       - Provide an executive summary of the patch changes, in a few
         sentences as well as bullet points if appropriate.
 
       - Choose a proposed release date at least several days in
         advance.
-      
+
    f. If there are any public CVE's, reference them in
       [SECURITY.md](SECURITY.md).
-      
+
    g. Submit the PR for others to review. The PR should go *to the
       release branch, not ``main``*, obviously.
 
@@ -611,9 +611,9 @@ The preferred workflow is:
    i. If further fixes come in that need to go into the release, push
       them to the PR branch. It's not absolutely essential that all
       changes to the release branch go in via a PR. The PR is simply a
-      convient forum for publicly discussing and reviewing the
+      convenient forum for publicly discussing and reviewing the
       composition of the release.
-   
+
 2. Tag the release with a ``-rc`` "release candidate" tag,
    e.g. ``v3.1.9-rc``.
 
@@ -636,7 +636,7 @@ The preferred workflow is:
 
    Create the release from the latest ``--rc`` tag, and give it a name
    that begins with ``v``, i.e. ``v3.1.9``.
-   
+
    Save the release as a "draft".
 
 6. Wait at least 48 hours, to give the community time to discover and
@@ -666,16 +666,16 @@ The preferred workflow is:
       with your GitHub account and git config.
 
    b. Create a signed tag with the release name via `git tag -s v3.1.9`.
-   
+
    c. Push the tag via `git push --tags`
-   
+
 8. Publish the release
 
    a. Click the "Publish release" button on the GitHub release draft
 
    b. Send an email to ``[email protected]`` officially
-      annoucing the release.
-   
+      announcing the release.
+
 9. Update the ``release`` branch, which should always point to the
    most recent patch of the most recent minor release, i.e. the most
    preferred release.
@@ -694,7 +694,7 @@ The preferred workflow is:
       the associated commit as well.
 
     - Also include in this PR edits to [``docs/news.rst``](docs/news.rst)
-      that add an announcment of the release.
+      that add an announcement of the release.
 
 11. After review/merge of the updates to ``docs/news.rst``, build the
     website at https://readthedocs.org/projects/openexr.
@@ -740,15 +740,15 @@ To create a new release from the ``main`` branch:
 
    - If there are any public CVE's, mention them explicitly with a
      link to the CVE registry item.
-   
+
    - Submit this change as a separate PR.
 
 3. Add a mention of the release to [``docs/news.rst``](docs/news.rst)
 
    - Submit this change as a separate PR.
 
 4. Increment the ``OPENEXR_LIB_SOVERSION`` setting in [CMakeLists.txt](CMakeLists.txt).
-   
+
    - The SO version increases whenever, and only when, the ABI changes
      in non-backwards-compatible ways. Consistent with the semantic
      versioning policy, this usually happens at major and minor
@@ -770,7 +770,7 @@ To create a new release from the ``main`` branch:
    of the release with link to the release candidate tag. Include the
    release notes from [CHANGES.md](CHANGES.md) for review.
 
-9. If additonal fixes need to go in before release:
+9. If additional fixes need to go in before release:
 
    a. Merge commits to the release branch. Push them directly, no need
       for a pull request.
@@ -790,7 +790,7 @@ To create a new release from the ``main`` branch:
 
     - Create the release from the latest ``--rc`` tag, and give it a name
       that begins with ``v`` and ends in ``0``, e.g. ``v3.2.0``.
-   
+
     - Save the release as a "draft".
 
 11. Wait at least 48 hours after the email announcement.
@@ -800,8 +800,8 @@ To create a new release from the ``main`` branch:
     a. Click the "Publish release" button on the GitHub release draft
 
     b. Send an email to ``[email protected]`` officially
-       annoucing the release.
-   
+       announcing the release.
+
 13. Update the ``release`` branch, which should always point to the
     most recent release.
 

SECURITY.md

@@ -22,27 +22,27 @@ These vulnerabilities are present in the given versions:
 
 * [CVE-2023-5841](https://nvd.nist.gov/vuln/detail/CVE-2023-5841) 3.1.0, 3.1.1, 3.1.2, 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 3.1.10 3.1.11 3.2.0 3.2.1
 * [CVE-2021-45942](https://nvd.nist.gov/vuln/detail/CVE-2021-45942) 3.1.0, 3.1.1, 3.1.2, 3.1.3
-* [CVE-2021-20296](https://nvd.nist.gov/vuln/detail/CVE-2021-20296) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
-* [CVE-2021-3479](https://nvd.nist.gov/vuln/detail/CVE-2021-3479) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
-* [CVE-2021-3478](https://nvd.nist.gov/vuln/detail/CVE-2021-3478) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
-* [CVE-2021-3477](https://nvd.nist.gov/vuln/detail/CVE-2021-3477) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
-* [CVE-2021-3476](https://nvd.nist.gov/vuln/detail/CVE-2021-3476) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
-* [CVE-2021-3475](https://nvd.nist.gov/vuln/detail/CVE-2021-3475) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
-* [CVE-2021-3474](https://nvd.nist.gov/vuln/detail/CVE-2021-3474) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3 
+* [CVE-2021-20296](https://nvd.nist.gov/vuln/detail/CVE-2021-20296) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
+* [CVE-2021-3479](https://nvd.nist.gov/vuln/detail/CVE-2021-3479) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
+* [CVE-2021-3478](https://nvd.nist.gov/vuln/detail/CVE-2021-3478) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
+* [CVE-2021-3477](https://nvd.nist.gov/vuln/detail/CVE-2021-3477) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
+* [CVE-2021-3476](https://nvd.nist.gov/vuln/detail/CVE-2021-3476) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
+* [CVE-2021-3475](https://nvd.nist.gov/vuln/detail/CVE-2021-3475) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
+* [CVE-2021-3474](https://nvd.nist.gov/vuln/detail/CVE-2021-3474) 2.4.0, 2.4.1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3
 * [CVE-2020-16589](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16589) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0
 * [CVE-2020-16588](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16588) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0
 * [CVE-2020-16587](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16587) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0
 * [CVE-2020-15306](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15306) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0, 2.4.1, 2.5.0, 2.5.1 
 * [CVE-2020-15305](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15305) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0, 2.4.1, 2.5.0, 2.5.1 
 * [CVE-2020-15304](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15304) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0, 2.4.1, 2.5.0, 2.5.1 
-* [CVE-2020-11765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11765) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11764](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11764) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11763](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11763) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11762](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11762) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11761](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11761) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11760](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11760) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11759](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11759) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
-* [CVE-2020-11758](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11758) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0 
+* [CVE-2020-11765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11765) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11764](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11764) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11763](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11763) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11762](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11762) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11761](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11761) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11760](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11760) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11759](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11759) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
+* [CVE-2020-11758](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11758) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0, 2.4.0
 * [CVE-2018-18444](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18444) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0
 * [CVE-2018-18443](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18443) 2.0.0, 2.0.1, 2.1.0, 2.2.0, 2.2.1, 2.3.0
 * [CVE-2017-9116](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9116) 2.0.0, 2.0.1, 2.1.0, 2.2.0
@@ -108,7 +108,7 @@ To verify a downloaded release at a given tag:
   The website implements no interactive features and requires no login
   credentials.
 
-- The library reads and writes only to file paths specificly requested
+- The library reads and writes only to file paths specifically requested
   via the C/C++ API. The runtime library uses no system configuration
   files or sidecar data files. Access to data files uses only standard
   file I/O system calls.
@@ -140,7 +140,7 @@ to scan for dependency vulnerability.
 Potential entry points are images being loaded using the
 library. Malformed images could caused issues such as heap buffer
 overflows, out-of-memory faults, or segmentation faults that could be
-exploitable as denial-of-service attacks. 
+exploitable as denial-of-service attacks.
 
 ### Hardening
 
@@ -172,6 +172,3 @@ changes are reviewed by multiple TSC members.
 
 The library is distributed in binary form via many common package
 managers across all platforms.
-
-
-

src/examples/deepExamples.cpp

@@ -47,7 +47,7 @@ readDeepScanlineFile (
     //    - allocate memory for the pixels
     //    - describe the layout of the A, and Z pixel buffers
     //    - read the sample counts from the file
-    //    - allocate the memory requred to store the samples
+    //    - allocate the memory required to store the samples
     //    - read the pixels from the file
     //
 

src/examples/deepTiledExamples.cpp

@@ -54,7 +54,7 @@ readDeepTiledFile (
     //    - allocate memory for the pixels
     //    - describe the layout of the A, and Z pixel buffers
     //    - read the sample counts from the file
-    //    - allocate the memory requred to store the samples
+    //    - allocate the memory required to store the samples
     //    - read the pixels from the file
     //
 

src/examples/multipartExamples.cpp

@@ -94,7 +94,7 @@ combineFiles ()
     //
     // Read multiple single-part input files and write them as a multi-part file.
     // If an input file is multi-part, only one part is copied.
-    // All input files dimentions must be the same.
+    // All input files dimensions must be the same.
     //
 
     std::vector<MultiPartInputFile*> inputFiles;

src/lib/OpenEXR/ImfChromaticities.cpp

@@ -6,7 +6,7 @@
 //-----------------------------------------------------------------------------
 //
 //	CIE (x,y) chromaticities, and conversions between
-//	RGB tiples and CIE XYZ tristimulus values.
+//	RGB triples and CIE XYZ tristimulus values.
 //
 //-----------------------------------------------------------------------------
 

src/lib/OpenEXR/ImfChromaticities.h

@@ -9,7 +9,7 @@
 //-----------------------------------------------------------------------------
 //
 //	CIE (x,y) chromaticities, and conversions between
-//	RGB tiples and CIE XYZ tristimulus values.
+//	RGB triples and CIE XYZ tristimulus values.
 //
 //-----------------------------------------------------------------------------
 

src/lib/OpenEXR/ImfInputFile.h

@@ -212,7 +212,7 @@ class IMF_EXPORT_TYPE InputFile
     // in a threadsafe manner (where the only way that was possible
     // before was to have a larger framebuffer, set the framebuffer
     // once, then call readPixels by the external threads, although
-    // that occured with a mutex and so the reads were serialized.
+    // that occurred with a mutex and so the reads were serialized.
     // There are reasons why that might still be serialized, such as a
     // non-threadable stream.
     //----------------------------------------------

src/lib/OpenEXR/ImfRgbaYca.h

@@ -47,7 +47,7 @@
 //		YCA  YCA  YCA  YCA  ... YCA  YCA
 //		YCA  YCA  YCA  YCA  ... YCA  YCA
 //
-//	Next, decimateChomaHoriz() eliminates the chroma values from
+//	Next, decimateChromaHoriz() eliminates the chroma values from
 //	the odd-numbered pixels in every scan line:
 //
 //		YCA  YA   YCA  YA   ... YCA  YA
@@ -152,7 +152,7 @@ void decimateChromaVert (int n, const Rgba* const ycaIn[N], Rgba ycaOut[/*n*/]);
 //
 // Round the luminance and chroma channels of an array of YCA
 // pixels that has already been filtered and subsampled.
-// The signifcands of the pixels' luminance and chroma values
+// The significands of the pixels' luminance and chroma values
 // are rounded to roundY and roundC bits respectively.
 //
 
@@ -175,7 +175,7 @@ reconstructChromaHoriz (int n, const Rgba ycaIn[/*n+N-1*/], Rgba ycaOut[/*n*/]);
 
 //
 // For a scan line that has only luminance and no valid chroma data,
-// reconstruct chroma from the surronding N scan lines.
+// reconstruct chroma from the surrounding N scan lines.
 //
 
 IMF_EXPORT

src/lib/OpenEXRCore/internal_dwa_encoder.h

@@ -860,7 +860,7 @@ static uint16_t algoQuantize (
     //
     // 99.99% of the time, the mask or round will be a good choice,
     // but only in a few combinations of tolerance will the truncation
-    // be needed because the mask trunction will be out of range,
+    // be needed because the mask truncation will be out of range,
     // which is not surprising given we're just shifting the
     // significand of the half-float tolerance, where the tolerance is
     // against the original 32-bit value, but can be quickly tested