Some mist. typo fixes

Found via `codespell -i 3 -w --skip="./3rdparty" -I ../opencv-whitelist.txt`

Author: luzpaz

CMakeLists.txt

@@ -34,7 +34,7 @@ set(CMAKE_POSITION_INDEPENDENT_CODE ${ENABLE_PIC})
 
 # Following block can break build in case of cross-compilng
 # but CMAKE_CROSSCOMPILING variable will be set only on project(OpenCV) command
-# so we will try to detect cross-compiling by presense of CMAKE_TOOLCHAIN_FILE
+# so we will try to detect cross-compiling by the presence of CMAKE_TOOLCHAIN_FILE
 if(NOT DEFINED CMAKE_INSTALL_PREFIX)
   if(NOT CMAKE_TOOLCHAIN_FILE)
     # it _must_ go before project(OpenCV) in order to work

cmake/FindCUDA.cmake

@@ -82,7 +82,7 @@
 #      CUDA_NVCC_FLAGS_<CONFIG> variables.  For Visual Studio targets,
 #      the host compiler is constructed with one or more visual studio macros
 #      such as $(VCInstallDir), that expands out to the path when
-#      the command is run from withing VS.
+#      the command is run from within VS.
 #
 #   CUDA_NVCC_FLAGS
 #   CUDA_NVCC_FLAGS_<CONFIG>
@@ -204,7 +204,7 @@
 #      The arguments passed in after OPTIONS are extra command line options to
 #      give to nvcc.  You can also specify per configuration options by
 #      specifying the name of the configuration followed by the options.  General
-#      options must preceed configuration specific options.  Not all
+#      options must precede configuration specific options.  Not all
 #      configurations need to be specified, only the ones provided will be used.
 #
 #         OPTIONS -DFLAG=2 "-DFLAG_OTHER=space in flag"
@@ -271,7 +271,7 @@
 #                            implementation (alternative to:
 #                            CUDA_ADD_CUFFT_TO_TARGET macro)
 #   CUDA_CUBLAS_LIBRARIES -- Device or emulation library for the Cuda BLAS
-#                            implementation (alterative to:
+#                            implementation (alternative to:
 #                            CUDA_ADD_CUBLAS_TO_TARGET macro).
 #   CUDA_cupti_LIBRARY    -- CUDA Profiling Tools Interface library.
 #                            Only available for CUDA version 4.0+.
@@ -493,7 +493,7 @@ mark_as_advanced(
 # Makefile and similar generators don't define CMAKE_CONFIGURATION_TYPES, so we
 # need to add another entry for the CMAKE_BUILD_TYPE.  We also need to add the
 # standerd set of 4 build types (Debug, MinSizeRel, Release, and RelWithDebInfo)
-# for completeness.  We need run this loop in order to accomodate the addition
+# for completeness.  We need run this loop in order to accommodate the addition
 # of extra configuration types.  Duplicate entries will be removed by
 # REMOVE_DUPLICATES.
 set(CUDA_configuration_types ${CMAKE_CONFIGURATION_TYPES} ${CMAKE_BUILD_TYPE} Debug MinSizeRel Release RelWithDebInfo)

cmake/FindCUDA/run_nvcc.cmake

@@ -167,14 +167,14 @@ if(CUDA_VERSION VERSION_LESS "3.0")
   # CMake policy 0007 NEW states that empty list elements are not
   # ignored.  I'm just setting it to avoid the warning that's printed.
   cmake_policy(SET CMP0007 NEW)
-  # Note that this will remove all occurances of -G.
+  # Note that this will remove all occurrences of -G.
   list(REMOVE_ITEM depends_CUDA_NVCC_FLAGS "-G")
   cmake_policy(POP)
 endif()
 
 # nvcc doesn't define __CUDACC__ for some reason when generating dependency files.  This
 # can cause incorrect dependencies when #including files based on this macro which is
-# defined in the generating passes of nvcc invokation.  We will go ahead and manually
+# defined in the generating passes of nvcc invocation.  We will go ahead and manually
 # define this for now until a future version fixes this bug.
 set(CUDACC_DEFINE -D__CUDACC__)
 

cmake/OpenCVCompilerOptions.cmake

@@ -134,7 +134,7 @@ if(CMAKE_COMPILER_IS_GNUCXX)
   endif()
   add_extra_compiler_option(-fdiagnostics-show-option)
 
-  # The -Wno-long-long is required in 64bit systems when including sytem headers.
+  # The -Wno-long-long is required in 64bit systems when including system headers.
   if(X86_64)
     add_extra_compiler_option(-Wno-long-long)
   endif()

cmake/OpenCVDetectCXXCompiler.cmake

@@ -96,7 +96,7 @@ if(NOT DEFINED OpenCV_STATIC)
 endif()
 
 if(DEFINED OpenCV_ARCH AND DEFINED OpenCV_RUNTIME)
-  # custom overrided values
+  # custom overridden values
 elseif(MSVC)
   if(CMAKE_CL_64)
     set(OpenCV_ARCH x64)

cmake/OpenCVDetectVTK.cmake

@@ -19,7 +19,7 @@ if(NOT VTK_FOUND)
   return()
 endif()
 
-# Don't support ealier VTKs
+# Don't support earlier VTKs
 if(${VTK_VERSION} VERSION_LESS "5.8.0")
   message(STATUS "VTK support is disabled. VTK ver. 5.8.0 is minimum required, but found VTK ver. ${VTK_VERSION}")
   return()

cmake/OpenCVModule.cmake

@@ -78,7 +78,7 @@ unset(OPENCV_WORLD_MODULES CACHE)
 # Usage:
 #   add_dependencies(opencv_<name> [REQUIRED] [<list of dependencies>] [OPTIONAL <list of modules>] [WRAP <list of wrappers>])
 # Notes:
-# * <list of dependencies> - can include full names of modules or full pathes to shared/static libraries or cmake targets
+# * <list of dependencies> - can include full names of modules or full paths to shared/static libraries or cmake targets
 macro(ocv_add_dependencies full_modname)
   ocv_debug_message("ocv_add_dependencies(" ${full_modname} ${ARGN} ")")
   #we don't clean the dependencies here to allow this macro several times for every module
@@ -138,7 +138,7 @@ macro(ocv_add_module _name)
 
   # the first pass - collect modules info, the second pass - create targets
   if(OPENCV_INITIAL_PASS)
-    #guard agains redefinition
+    #guard against redefinition
     if(";${OPENCV_MODULES_BUILD};${OPENCV_MODULES_DISABLED_USER};" MATCHES ";${the_module};")
       message(FATAL_ERROR "Redefinition of the ${the_module} module.
   at:                    ${CMAKE_CURRENT_SOURCE_DIR}
@@ -407,7 +407,7 @@ function(__ocv_sort_modules_by_deps __lst)
             break()
           endif()
         endforeach()
-        # chek if all dependencies for this module has been resolved
+        # check if all dependencies for this module has been resolved
         if (NOT unresolved_deps_found)
           list(APPEND result ${m})
           list(REMOVE_ITEM input ${m})

cmake/OpenCVPCHSupport.cmake

@@ -319,7 +319,7 @@ ENDMACRO(ADD_PRECOMPILED_HEADER)
 
 
 # Generates the use of precompiled in a target,
-# without using depency targets (2 extra for each target)
+# without using dependency targets (2 extra for each target)
 # Using Visual, must also add ${_targetName}_pch to sources
 # Not needed by Xcode
 
@@ -346,7 +346,7 @@ MACRO(ADD_NATIVE_PRECOMPILED_HEADER _targetName _input)
 
         # Auto include the precompile (useful for moc processing, since the use of
         # precompiled is specified at the target level
-        # and I don't want to specifiy /F- for each moc/res/ui generated files (using Qt)
+        # and I don't want to specify /F- for each moc/res/ui generated files (using Qt)
 
         get_target_property(_sources ${_targetName} SOURCES)
         foreach(src ${_sources})
@@ -392,7 +392,7 @@ MACRO(ADD_NATIVE_PRECOMPILED_HEADER _targetName _input)
 
     else()
 
-        #Fallback to the "old" precompiled suppport
+        #Fallback to the "old" precompiled support
         #ADD_PRECOMPILED_HEADER(${_targetName} ${_input} ${_dowarn})
 
     endif()

cmake/templates/OpenCVConfig.cmake.in

@@ -80,7 +80,7 @@ set(OpenCV_CONFIG_PATH "${CMAKE_CURRENT_LIST_DIR}")
 get_filename_component(OpenCV_INSTALL_PATH "${OpenCV_CONFIG_PATH}/@OpenCV_INSTALL_PATH_RELATIVE_CONFIGCMAKE@" REALPATH)
 
 # Search packages for host system instead of packages for target system.
-# in case of cross compilation thess macro should be defined by toolchain file
+# in case of cross compilation this macro should be defined by toolchain file
 if(NOT COMMAND find_host_package)
     macro(find_host_package)
         find_package(${ARGN})

cmake/templates/OpenCVConfig.root-WIN32.cmake.in

@@ -58,7 +58,7 @@ if(NOT DEFINED OpenCV_CUDA)
 endif()
 
 if(DEFINED OpenCV_ARCH AND DEFINED OpenCV_RUNTIME)
-  # custom overrided values
+  # custom overridden values
 elseif(MSVC)
   if(CMAKE_CL_64)
     set(OpenCV_ARCH x64)

data/haarcascades/haarcascade_fullbody.xml

@@ -118,14 +118,14 @@ www.vision.ethz.ch/kruppa/
 
 KNOWN LIMITATIONS
 ==================
-1) the detectors only support frontal and back views but not sideviews.
+1) The detectors only support frontal and back views but not sideviews.
    Sideviews are trickier and it makes a lot of sense to include additional
    modalities for their detection, e.g. motion information. I recommend
    Viola and Jones' ICCV 2003 paper if this further interests you.
 
-2) dont expect these detectors to be as accurate as a frontal face detector.
+2) Don't expect these detectors to be as accurate as a frontal face detector.
    A frontal face as a pattern is pretty distinct with respect to other
-   patterns occuring in the world (i.e. image "background"). This is not so
+   patterns occurring in the world (i.e. image "background"). This is not so
    for upper, lower and especially full bodies, because they have to rely
    on fragile silhouette information rather than internal (facial) features.
    Still, we found especially the upper body detector to perform amazingly well.

data/haarcascades/haarcascade_lowerbody.xml

@@ -118,14 +118,14 @@ www.vision.ethz.ch/kruppa/
 
 KNOWN LIMITATIONS
 ==================
-1) the detectors only support frontal and back views but not sideviews.
+1) The detectors only support frontal and back views but not sideviews.
    Sideviews are trickier and it makes a lot of sense to include additional
    modalities for their detection, e.g. motion information. I recommend
    Viola and Jones' ICCV 2003 paper if this further interests you.
 
-2) dont expect these detectors to be as accurate as a frontal face detector.
+2) Don't expect these detectors to be as accurate as a frontal face detector.
    A frontal face as a pattern is pretty distinct with respect to other
-   patterns occuring in the world (i.e. image "background"). This is not so
+   patterns occurring in the world (i.e. image "background"). This is not so
    for upper, lower and especially full bodies, because they have to rely
    on fragile silhouette information rather than internal (facial) features.
    Still, we found especially the upper body detector to perform amazingly well.

data/haarcascades/haarcascade_upperbody.xml

@@ -118,14 +118,14 @@ www.vision.ethz.ch/kruppa/
 
 KNOWN LIMITATIONS
 ==================
-1) the detectors only support frontal and back views but not sideviews.
+1) The detectors only support frontal and back views but not sideviews.
    Sideviews are trickier and it makes a lot of sense to include additional
    modalities for their detection, e.g. motion information. I recommend
    Viola and Jones' ICCV 2003 paper if this further interests you.
 
-2) dont expect these detectors to be as accurate as a frontal face detector.
+2) Don't expect these detectors to be as accurate as a frontal face detector.
    A frontal face as a pattern is pretty distinct with respect to other
-   patterns occuring in the world (i.e. image "background"). This is not so
+   patterns occurring in the world (i.e. image "background"). This is not so
    for upper, lower and especially full bodies, because they have to rely
    on fragile silhouette information rather than internal (facial) features.
    Still, we found especially the upper body detector to perform amazingly well.

data/haarcascades_cuda/haarcascade_fullbody.xml

@@ -118,14 +118,14 @@ www.vision.ethz.ch/kruppa/
 
 KNOWN LIMITATIONS
 ==================
-1) the detectors only support frontal and back views but not sideviews.
+1) The detectors only support frontal and back views but not sideviews.
    Sideviews are trickier and it makes a lot of sense to include additional
    modalities for their detection, e.g. motion information. I recommend
    Viola and Jones' ICCV 2003 paper if this further interests you.
 
-2) dont expect these detectors to be as accurate as a frontal face detector.
+2) Don't expect these detectors to be as accurate as a frontal face detector.
    A frontal face as a pattern is pretty distinct with respect to other
-   patterns occuring in the world (i.e. image "background"). This is not so
+   patterns occurring in the world (i.e. image "background"). This is not so
    for upper, lower and especially full bodies, because they have to rely
    on fragile silhouette information rather than internal (facial) features.
    Still, we found especially the upper body detector to perform amazingly well.

data/haarcascades_cuda/haarcascade_lowerbody.xml

@@ -118,14 +118,14 @@ www.vision.ethz.ch/kruppa/
 
 KNOWN LIMITATIONS
 =================
-1) the detectors only support frontal and back views but not sideviews.
+1) The detectors only support frontal and back views but not sideviews.
    Sideviews are trickier and it makes a lot of sense to include additional
    modalities for their detection, e.g. motion information. I recommend
    Viola and Jones' ICCV 2003 paper if this further interests you.
 
-2) dont expect these detectors to be as accurate as a frontal face detector.
+2) Don't expect these detectors to be as accurate as a frontal face detector.
    A frontal face as a pattern is pretty distinct with respect to other
-   patterns occuring in the world (i.e. image "background"). This is not so
+   patterns occurring in the world (i.e. image "background"). This is not so
    for upper, lower and especially full bodies, because they have to rely
    on fragile silhouette information rather than internal (facial) features.
    Still, we found especially the upper body detector to perform amazingly well.

data/haarcascades_cuda/haarcascade_upperbody.xml

@@ -118,14 +118,14 @@ www.vision.ethz.ch/kruppa/
 
 KNOWN LIMITATIONS
 ==================
-1) the detectors only support frontal and back views but not sideviews.
+1) The detectors only support frontal and back views but not sideviews.
    Sideviews are trickier and it makes a lot of sense to include additional
    modalities for their detection, e.g. motion information. I recommend
    Viola and Jones' ICCV 2003 paper if this further interests you.
 
-2) dont expect these detectors to be as accurate as a frontal face detector.
+2) Don't expect these detectors to be as accurate as a frontal face detector.
    A frontal face as a pattern is pretty distinct with respect to other
-   patterns occuring in the world (i.e. image "background"). This is not so
+   patterns occurring in the world (i.e. image "background"). This is not so
    for upper, lower and especially full bodies, because they have to rely
    on fragile silhouette information rather than internal (facial) features.
    Still, we found especially the upper body detector to perform amazingly well.