Fixed several doc typos (#2068)

Co-authored-by: Ginés Hidalgo <gineshidalgo99@gmail.com>

Author: luzpaz

.github/CI_deprecated/generate_gh_pages.sh

@@ -9,7 +9,7 @@ __AUTHOR__="openpose"
 #   must be installed.
 # - Doxygen configuration file must have the destination directory empty and
 #   source code directory with a $(CI_BUILD_DIR) prefix.
-# - An gh-pages branch should already exist. See below for mor info on hoe to
+# - An gh-pages branch should already exist. See below for more info on how to
 #   create a gh-pages branch.
 #
 # Required global variables:
@@ -93,7 +93,7 @@ if [ -d "html" ] && [ -f "html/index.html" ]; then
     git commit -m "Deploy code docs to GitHub Pages Travis build: ${CI_BUILD_NUMBER}" -m "Commit: ${CI_COMMIT}"
 
     # Force push to the remote gh-pages branch.
-    # The ouput is redirected to /dev/null to hide any sensitive credential data
+    # The output is redirected to /dev/null to hide any sensitive credential data
     # that might otherwise be exposed.
     git push --force "https://${GH_REPO_TOKEN}@${GH_REPO_REF}" > /dev/null 2>&1
 else

CMakeLists.txt

@@ -265,7 +265,7 @@ endif (PROFILER_ENABLED)
 
 # Suboptions for GPU architectures
 if (${GPU_MODE} MATCHES "CUDA")
-  set(CUDA_ARCH Auto CACHE STRING "Select target NVIDIA GPU achitecture.")
+  set(CUDA_ARCH Auto CACHE STRING "Select target NVIDIA GPU architecture.")
   set_property(CACHE CUDA_ARCH PROPERTY STRINGS Auto All Manual)
 endif (${GPU_MODE} MATCHES "CUDA")
 

cmake/Cuda.cmake

@@ -76,7 +76,7 @@ function(op_detect_installed_gpus out_variable)
       if (NOT WIN32)
         string(REPLACE "2.1" "2.1(2.0)" __nvcc_out "${__nvcc_out}")
       endif (NOT WIN32)
-      set(CUDA_gpu_detect_output ${__nvcc_out} CACHE INTERNAL "Returned GPU architetures from op_detect_gpus tool" FORCE)
+      set(CUDA_gpu_detect_output ${__nvcc_out} CACHE INTERNAL "Returned GPU architectures from op_detect_gpus tool" FORCE)
     endif ()
   endif ()
 
@@ -104,14 +104,14 @@ function(op_select_nvcc_arch_flags out_variable)
   endif ()
 
   # set CUDA_ARCH strings (so it will be seen as dropbox in CMake-Gui)
-  # set(CUDA_ARCH ${__archs_name_default} CACHE STRING "Select target NVIDIA GPU achitecture.")
+  # set(CUDA_ARCH ${__archs_name_default} CACHE STRING "Select target NVIDIA GPU architecture.")
   # set_property( CACHE CUDA_ARCH PROPERTY STRINGS "" ${__archs_names} )
   # mark_as_advanced(CUDA_ARCH)
 
   # verify CUDA_ARCH value
   if (NOT ";${__archs_names};" MATCHES ";${CUDA_ARCH};")
     string(REPLACE ";" ", " __archs_names "${__archs_names}")
-    message(FATAL_ERROR "Only ${__archs_names} architeture names are supported.")
+    message(FATAL_ERROR "Only ${__archs_names} architecture names are supported.")
   endif ()
 
   if (${CUDA_ARCH} STREQUAL "Manual")

doc/01_demo.md

@@ -233,7 +233,7 @@ bin\OpenPoseDemo.exe --flir_camera --3d --number_people_max 1 --face --hand
 ./build/examples/openpose/openpose.bin --flir_camera --num_gpu 0 --write_images output_folder_path/ --write_images_format jpg
 ```
 
-4. Reading and processing previouly saved stereo camera images
+4. Reading and processing previously saved stereo camera images
 ```
 # Ubuntu and Mac (same flags for Windows)
 # Optionally add `--face` and/or `--hand` to include face and/or hands
@@ -348,7 +348,7 @@ Additional notes:
 ### Mac OSX Additional Step
 **If you are not using Mac, or you are using Mac with `CPU_only`, you can skip this section.**
 
-If you are using a Mac and selected `OPENCL` support, and it has an AMD graphics card, that means that the machine has 2 GPUs that are not compatible with each other (AMD and Intel). Then, you will have to manually select one of them (the AMD one should be more poweful). To do that, first check which device your Graphics card is set under. Most likely, your AMD device will be device 2.
+If you are using a Mac and selected `OPENCL` support, and it has an AMD graphics card, that means that the machine has 2 GPUs that are not compatible with each other (AMD and Intel). Then, you will have to manually select one of them (the AMD one should be more powerful). To do that, first check which device your Graphics card is set under. Most likely, your AMD device will be device 2.
 ```bash
 clinfo
 ```

doc/03_python_api.md

@@ -24,7 +24,7 @@ You should be familiar with the [**OpenPose Demo**](01_demo.md) and the main Ope
 ## Advance Introduction (Optional)
 This module exposes a Python API for OpenPose. It is effectively a wrapper that replicates most of the functionality of the [op::Wrapper class](https://github.com/CMU-Perceptual-Computing-Lab/openpose/blob/master/include/openpose/wrapper/wrapper.hpp) and allows you to populate and retrieve data from the [op::Datum class](https://github.com/CMU-Perceptual-Computing-Lab/openpose/blob/master/include/openpose/core/datum.hpp) using standard Python and Numpy constructs.
 
-The Python API is analagous to the C++ function calls. You may find them in [python/openpose/openpose_python.cpp#L194](https://github.com/CMU-Perceptual-Computing-Lab/openpose/blob/master/python/openpose/openpose_python.cpp#L194).
+The Python API is analogous to the C++ function calls. You may find them in [python/openpose/openpose_python.cpp#L194](https://github.com/CMU-Perceptual-Computing-Lab/openpose/blob/master/python/openpose/openpose_python.cpp#L194).
 
 The Python API is rather simple: `op::Array<float>` and `cv::Mat` objects get casted to numpy arrays automatically. Every other data structure based on the standard library is automatically converted into Python objects. For example, an `std::vector<std::vector<float>>` would become `[[item, item], [item, item]]`, etc. We also provide a casting of `op::Rectangle` and `op::Point` which simply expose setter getter for [x, y, width, height], etc.
 
@@ -90,7 +90,7 @@ For quick prototyping, you can simply duplicate and rename any of the existing s
 
 
 ## Exporting Python OpenPose
-Note: This step is only required if you are moving the `*.py` files outside their original location, or writting new `*.py` scripts outside `build/examples/tutorial_api_python`.
+Note: This step is only required if you are moving the `*.py` files outside their original location, or writing new `*.py` scripts outside `build/examples/tutorial_api_python`.
 
 Ubuntu/OSX:
 

doc/05_faq.md

@@ -41,7 +41,7 @@ OpenPose Doc - Frequently Asked Questions (FAQ)
 ## FAQ
 ### Errors
 #### Download Server Down
-**Q: The download server is down, Download Hash missmatch, Error 502: Bad Gateway, etc. I.e., I cannot download the OpenPose models and/or 3rd party libraries.**
+**Q: The download server is down, Download Hash mismatch, Error 502: Bad Gateway, etc. I.e., I cannot download the OpenPose models and/or 3rd party libraries.**
 **A**: The are 2 alternatives. Option 1 (recommended): Download the links from [1602#issuecomment-641653411](https://github.com/CMU-Perceptual-Computing-Lab/openpose/issues/1602#issuecomment-641653411) and download them in the places indicated by [doc/1_prerequisites.md](1_prerequisites.md). Option 2: If you downloaded the models and dependencies to some local server, you could set the advanced CMake property `DOWNLOAD_SERVER` to link OpenPose to your local mirror server instead.
 
 
@@ -261,7 +261,7 @@ Check the [doc/06_maximizing_openpose_speed.md#profiling-speed](06_maximizing_op
 COCO model will eventually be removed. BODY_25 model is faster, more accurate, and it includes foot keypoints. However, `COCO` requires less memory on GPU (being able to fit into 2GB GPUs with the default settings) and it runs faster on CPU-only mode. `MPI` model is only meant for people requiring the MPI-keypoint structure. It is also slower than BODY_25 and far less accurate.
 
 Key differences:
-- `BODY_25` is the fastest one on the GPU, the most accurate one, and the one with the highest number of keypoints (including foot keypoints!), highly recommended. It also uses the most ammount of RAM/GPU memory.
+- `BODY_25` is the fastest one on the GPU, the most accurate one, and the one with the highest number of keypoints (including foot keypoints!), highly recommended. It also uses the most amount of RAM/GPU memory.
 - `COCO` is faster than `BODY_25` on the CPU but slower on the GPU and less accurate.
 - `MPI` is the fastest on the CPU but the least accurate of all 3.
 

doc/06_maximizing_openpose_speed.md

@@ -28,7 +28,7 @@ On Ubuntu (for OS versions older than 20), you can also boost CPU-only speed by
 OpenPose displays the FPS in the basic GUI. However, more complex speed metrics can be obtained from the command line while running OpenPose. In order to obtain those, compile OpenPose with the `PROFILER_ENABLED` flag on CMake-gui. OpenPose will automatically display time measurements for each subthread after processing `F` frames (by default `F = 1000`, but it can be modified with the `--profile_speed` flag, e.g. `--profile_speed 100`).
 
 - Time measurement for 1 graphic card: The FPS will be the slowest time displayed in your terminal command line (as OpenPose is multi-threaded). Times are in milliseconds, so `FPS = 1000/millisecond_measurement`.
-- Time measurement for >1 graphic cards: Assuming `n` graphic cards, you will have to wait up to `n` x `F` frames to visualize each graphic card speed (as the frames are splitted among them). In addition, the FPS would be: `FPS = minFPS(speed_per_GPU/n, worst_time_measurement_other_than_GPUs)`. For < 4 GPUs, this is usually `FPS = speed_per_GPU/n`.
+- Time measurement for >1 graphic cards: Assuming `n` graphic cards, you will have to wait up to `n` x `F` frames to visualize each graphic card speed (as the frames are split among them). In addition, the FPS would be: `FPS = minFPS(speed_per_GPU/n, worst_time_measurement_other_than_GPUs)`. For < 4 GPUs, this is usually `FPS = speed_per_GPU/n`.
 
 Make sure that `wPoseExtractor` time is the slowest timing. Otherwise the input producer (video/webcam codecs issues with OpenCV, images too big, etc.) or the GUI display (use OpenGL support as detailed in the next section (`Speed Up Preserving Accuracy`) might not be optimized.
 

doc/08_release_notes.md

@@ -160,7 +160,7 @@ OpenPose Doc - Release Notes
     5. Added `--write_json` as a new version of `--write_keypoint_json`. It includes the body part candidates (if enabled), as well as any extra information added in the future (e.g., person ID).
     6. Body part candidates can be retrieved in Datum and saved with `--write_json`.
 2. Functions or parameters renamed:
-    1. `PoseParameters` splitted into `PoseParameters` and `PoseParametersRender` and const parameters turned into functions for more clarity.
+    1. `PoseParameters` split into `PoseParameters` and `PoseParametersRender` and const parameters turned into functions for more clarity.
 3. Main bugs fixed:
     1. Render working on images > 4K (#324).
     2. Cleaned redundant arguments on `getAverageScore` and `getKeypointsArea`.
@@ -235,7 +235,7 @@ OpenPose Doc - Release Notes
     11. 3D keypoints and camera parameters in meters (instead of millimeters) in order to reduce numerical errors.
     12. New `PoseExtractor` class to contain future ID and tracking algorithms as well as the current OpenPose keypoint detection algorithm.
     13. Added initial alpha versions of the `tracking` and `identification` modules (for now disabled but available in the source code), including `PersonIdExtractor` and `PersonTracker`. `PersonIdExtractor` includes greedy matrix OP-LK matching.
-    14. Added catchs to all demos for higher debug information.
+    14. Added catches to all demos for higher debug information.
     15. GUI includes the capability of dynamically enabling/disabling the face, hand, and 3-D rendering, as well as more clear visualization for skeleton, background, heatmap addition, and PAF addition channels.
     16. When GUI changes some parameter from PoseExtractorNet, there is a log to notify the user of the change.
     17. Deprecated flag `--write_keypoint_json` removed (`--write_json` is the equivalent since version 1.2.1).
@@ -387,7 +387,7 @@ OpenPose Doc - Release Notes
 1. Main improvements:
     1. Multi-camera (3D) working on Asynchronous mode.
         1. Functions `WrapperT::waitAndEmplace()` and `WrapperT::tryEmplace()` improved, allowing multi-camera/3-D (`TDatums` of size > 1).
-        2. Added `createMultiviewTDatum()` to auto-generate a `TDatums` for multi-camera/3-D from a single cv::Mat (that is splitted) and the desired camera parameter matrices.
+        2. Added `createMultiviewTDatum()` to auto-generate a `TDatums` for multi-camera/3-D from a single cv::Mat (that is split) and the desired camera parameter matrices.
         3. Added `examples/tutorial_api_cpp/11_asynchronous_custom_input_multi_camera.cpp` for a test example.
     2. Created Matrix as container of cv::Mat, and String as container of std::string.
     3. After replacing cv::Mat by Matrix, headers do not contain any 3rd-party library includes nor functions. This way, OpenPose can be exported without needing 3rd-party includes nor static library files (e.g., lib files in Windows), allowing people to use their own versions of OpenCV, Eigen, etc. without conflicting with OpenPose. Dynamic library files (e.g., `dll` files in Windows, `so` in Ubuntu) are still required.

doc/09_authors_and_contributors.md

@@ -14,7 +14,7 @@ OpenPose would not be possible without the [**CMU Panoptic Studio dataset**](htt
 We would also like to thank the following people, who have contributed to key components of OpenPose:
 1. [Bikramjot Hanzra](https://www.linkedin.com/in/bikz05): Former OpenPose maintainer, CMake (Ubuntu and Windows) version, and initial Travis Build version for Ubuntu.
 2. [Donglai Xiang](https://xiangdonglai.github.io): Camera calibration toolbox improvement, including the implementation of its bundle adjustment algorithm.
-3. [Luis Fernando Fraga](https://github.com/fragalfernando): Implementation of Lukas-Kanade algorith and person ID extractor.
+3. [Luis Fernando Fraga](https://github.com/fragalfernando): Implementation of Lukas-Kanade algorithm and person ID extractor.
 4. [Akash Patwal](https://www.linkedin.com/in/akash-patwal-63a12012a): Speedup of the CUDA image resize and visual skeleton rendering, as well as extension that allows OpenPose to speedup linearly to more than 4 GPUs.
 5. [Helen Medina](https://github.com/helen-medina): First Windows version.
 6. [Matthijs van der Burgh](https://github.com/MatthijsBurgh): First GitHub Actions CI version for Ubuntu and Mac, and ported all the deprecated Travis CI tests into the new CI system.

doc/advanced/calibration_module.md

@@ -39,7 +39,7 @@ Check [doc/installation/0_index.md#calibration-module](../installation/0_index.m
 Note: In order to maximize calibration quality, **do not reuse the same video sequence for both intrinsic and extrinsic parameter estimation**. The intrinsic parameter calibration should be run camera by camera, where each recorded video sequence should be focused in covering all regions of the camera view and repeated from several distances. In the extrinsic sequence, this video sequence should be focused in making sure that the checkboard is visible from at least 2 cameras at the time. So for 3-camera calibration, you would need 1 video sequence per camera as well as a final sequence for the extrinsic parameter calibration.
 
 ### General Quality Tips
-1. Keep the same orientation of the chessboard, i.e., do not rotate it circularly more than ~15-30 degress with respect to its center (i.e., going from a `w` x `h` number of squares to a `h` x `w` one). Our algorithm assumes that the origin is the corner at the top left, so rotating the chessboard circularly will change this origin across frames, resulting in many frames being rejected for the final calibration, i.e., lower calibration accuracy.
+1. Keep the same orientation of the chessboard, i.e., do not rotate it more than ~15-30 degrees with respect to its center (i.e., going from a `w` x `h` number of squares to a `h` x `w` one). Our algorithm assumes that the origin is the corner at the top left, so rotating the chessboard will change this origin across frames, resulting in many frames being rejected for the final calibration, i.e., lower calibration accuracy.
 2. Cover several distances, and within each distance, cover all parts of the image view (all corners and center).
 3. Save the images in PNG format (default behavior) in order to improve calibration quality. PNG images are bigger than JPG equivalent, but do not lose information by compression.
 4. Use a chessboard as big as possible, ideally a chessboard with of at least 8x6 squares with a square size of at least 100 millimeters. It will specially affect the extrinsic calibration quality.