More typos

toolbox/mexutils.h

@@ -267,7 +267,7 @@ uIsRealVector(const mxArray* A, int N)
  ** - It is real (see ::uIsReal()).
  ** - @a ndims < 0 or it has @a ndims dimensions and
  **   - for each element of @a dims, either that element is negative
- **     or it is equal to the corresponding dimesion of the array.
+ **     or it is equal to the corresponding dimension of the array.
  **
  ** @return test result.
  **/
@@ -337,15 +337,15 @@ struct _uMexOption
   int val ;          /**< value to return */
 } ;
 
-/** @brief MEX opion type
+/** @brief MEX option type
  ** @see ::_uMexOption
  **/
 typedef struct _uMexOption uMexOption ;
 
 /** ------------------------------------------------------------------
  ** @brief Case insensitive string comparison
  **
- ** @param s1 fisrt string.
+ ** @param s1 first string.
  ** @param s2 second string.
  **
  ** @return 0 if the strings are equal, >0 if the first string is
@@ -380,15 +380,15 @@ uStrICmp(const char *s1, const char *s2)
  ** The function scans the MEX driver arguments array @a args of @a
  ** nargs elements for the next option starting at location @a next.
  **
- ** This argument is suppsed to be the name of an option (case
+ ** This argument is supposed to be the name of an option (case
  ** insensitive). The option is looked up in the option table @a
  ** options and decoded as the value uMexOption::val. Furthermore, if
  ** uMexOption::has_arg is true, the next entry in the array @a args
  ** is assumed to be argument of the option and stored in @a
  ** optarg. Finally, @a next is advanced to point to the next option.
  **
  ** @return the code of the option, or -1 if the argument list is
- ** exhausetd. In case of an error (e.g. unknown option) the function
+ ** exhausted. In case of an error (e.g. unknown option) the function
  ** prints an error message and quits the MEX file.
  **/
 
@@ -423,7 +423,7 @@ static int uNextOption(mxArray const *args[], int nargs,
     mexErrMsgTxt(err_msg) ;    
   }
 
-  /* advance argumnt list */
+  /* advance argument list */
   ++ (*next) ;
 
   /* now lookup the string in the option table */

toolbox/sift/dhog.c

@@ -32,13 +32,13 @@ uMexOption options [] = {
 
 /** ------------------------------------------------------------------
  ** @internal
- ** @brief Transpose desriptor
+ ** @brief Transpose descriptor
  **
  ** @param dst destination buffer.
  ** @param src source buffer.
  **
  ** The function writes to @a dst the transpose of the SIFT descriptor
- ** @a src. The tranpsose is defined as the descriptor that one
+ ** @a src. The transpose is defined as the descriptor that one
  ** obtains from computing the normal descriptor on the transposed
  ** image.
  **/

toolbox/sift/dhog.m

@@ -3,8 +3,8 @@
 %  descriptors for image I. I must be grayscale in SINGLE format.
 %
 %  A DHOG descriptor is equivalent to a SIFT descriptor (see SIFT()
-%  and VLFeat API documentation). This function calculate quickly a
-%  large number of such descriptors, for a dense covering of the image
+%  and VLFeat API documentation). This function quickly calculates a
+%  large number of such descriptors for a dense covering of the image
 %  with features of the same size and orientation.
 %
 %  The function returns the frames F and the descriptors D. Since all
@@ -15,7 +15,7 @@
 %  bins in each spatial direction (by default 4), then a DHOG keypoint
 %  covers a square patch of NS by SIZE pixels.
 %
-%  Remark:: The size of a SIFT bin is equal to the the magnification
+%  Remark:: The size of a SIFT bin is equal to the magnification
 %    factor MAGNIF (usually 3) by the scale of the SIFT keypoint. For
 %    instance, the scale that should be fed to SIFTDESCRIPTOR() in
 %    order to match the output of DHOG() is equal to SIFT / MAGNIF.

toolbox/sift/siftdescriptor.c

@@ -26,13 +26,13 @@ uMexOption options [] = {
 
 /** ------------------------------------------------------------------
  ** @internal
- ** @brief Transpose desriptor
+ ** @brief Transpose descriptor
  **
  ** @param dst destination buffer.
  ** @param src source buffer.
  **
  ** The function writes to @a dst the transpose of the SIFT descriptor
- ** @a src. The tranpsose is defined as the descriptor that one
+ ** @a src. The transpose is defined as the descriptor that one
  ** obtains from computing the normal descriptor on the transposed
  ** image.
  **/

toolbox/sift/siftdescriptor.m

@@ -1,6 +1,6 @@
 % SIFTDESCRIPTOR   Run SIFT descriptor on raw data
 %  D = SIFTDESCRIPTOR(GRAD, F) calculates the SIFT descriptors of
-%  thekeypoints F on the pre-processed image GRAD. GRAD is a 2xMxN
+%  the keypoints F on the pre-processed image GRAD. GRAD is a 2xMxN
 %  array. The first layer GRAD(1,:,:) contains the modulus of gradient
 %  of the original image modulus. The second layer GRAD(2,:,:)
 %  contains the gradient angle (measured in radians, clockwise,

vl/dhog.c

@@ -39,7 +39,7 @@ int const NBO = 8 ;
  
  The top row shows bins of extension @f$\Delta=2@f$ whose center is aligned
  to a pixel. The bottom row shows the same bins, but whose center sits
- in between two adjacent pixels. Notice that, while the bin extent is always
+ in between two adjacent pixels. Notice that while the bin extent is always
  the same, in the first case
  the pixels that actually contributes to a bin (i.e. the ones with weights
  greater than zero) are @f$2\Delta -1@f$, while in the second case
@@ -51,14 +51,13 @@ int const NBO = 8 ;
  
  @section dhog-grid Covering with descriptor and downsampling
  
- DHOG extract a dense collection of descriptor, one each few pixels.
- How many descriptors can be computed out of an image? Since 
- most caluclations are going to be done by convolutions, for simplicity we require
+ DHOG extracts a dense collection of descriptors, one each few pixels.
+ Since most calculations use convolutions, for simplicity we require
  the centers of all descriptor bins to lie at integer coordinates within
  the image boundaries.
  
  The center of the top-left bin of the top-left descriptor has
- have coordinates 
+ coordinates 
  @f[
  x_0(0) = 0,\qquad y_0(0) = 0 
  @f]

vl/host.c

@@ -30,13 +30,13 @@
  
  @section host-os Host operating system
  
- The module defines a symbol to indentify the host operating system:
+ The module defines a symbol to identify the host operating system:
  ::VL_OS_WIN for Windows, ::VL_OS_LINUX for Linux, ::VL_OS_MACOSX for
  Mac OS X, and so on.
  
  @section host-compiler Host compiler 
  
- The module defines a symbol to indetify the host compiler:
+ The module defines a symbol to identify the host compiler:
  ::VL_COMPILER_MSC for Microsoft Visual C++, ::VL_COMPILER_GNUC for GNU C,
  and so on. The (integer) value of such symbols 
  corresponds the version of the  compiler.
@@ -59,7 +59,7 @@
  The following table summarizes the relevant conventions:
  
  <table><caption><b>Compiler data models.</b> The table shows
- how many bits are allocated to each tomic data type according to
+ how many bits are allocated to each atomic data type according to
  each model.</caption>
  <tr style="font-weight:bold;">
  <td>Data model</td>
@@ -199,7 +199,7 @@
 
  @subsection host-arch-endianness Endianness
  
- The module defines a symbol to identify the host CPU enianness:
+ The module defines a symbol to identify the host CPU endianness:
  ::VL_ARCH_BIG_ENDIAN for big endian and ::VL_ARCH_LITTLE_ENDIAN for
  little endian. The functions 
  ::vl_swap_host_big_endianness_8(), ::vl_swap_host_big_endianness_4(),
@@ -208,8 +208,8 @@
  
  Recall that <em>endianness</em> concerns the way multi-byte data types 
  (such as 16, 32 and 64 bits
- integres) are stored into the addressable memory. 
- All CPUs uses a continguous address range to store atomic data types
+ integers) are stored into the addressable memory. 
+ All CPUs uses a contiguous address range to store atomic data types
  (e.g. a 16-bit integer could
  be assigned to the addresses <c>0x10001</c> and <c>0x10002</c>), but
  the order may differ.
@@ -229,7 +229,7 @@
  &ldquo;little endian&rdquo; means &ldquo;little endian first&rdquo;, 
  in the sense that the address of the least significant byte comes first.
 
- Endianness is a concern when data is either exchangend with processors
+ Endianness is a concern when data is either exchanged with processors
  that use different conventions, 
  transmitted over a network, or stored
  to a file. For the latter two cases, one usually saves data in 
@@ -257,7 +257,7 @@
  ** @brief Defined if the host compiler is GNU C.
  **
  ** This macro is defined if the compiler is GNUC.
- ** Its value is caluclated as
+ ** Its value is calculated as
  ** @code
  ** 10000 * MAJOR + 100 * MINOR + PATCHLEVEL
  ** @endcode

vl/imopv.c

@@ -35,7 +35,7 @@
 /** @fn vl_imconvcol_vf(float*,int,float const*,int,int,int,float const*,int,int,int,unsigned int)
  ** @brief Convolve image along columns
  **
- ** @param dst destinaton image.
+ ** @param dst destination image.
  ** @param dst_stride width of the destination image including padding.
  ** @param src source image.
  ** @param src_width width of the source image.
@@ -82,7 +82,7 @@
 /** @fn vl_imconvcoltri_vf(float*,int,float const*,int,int,int,int,int,unsigned int)
  ** @brief Convolve image along columns by a triangular kernel
  **
- ** @param dst destinaton image.
+ ** @param dst destination image.
  ** @param dst_stride width of the destination image including padding.
  ** @param src source image.
  ** @param src_width width of the source image.
@@ -101,4 +101,4 @@
 
 /** @fn vl_imconvcoltri_vd(double*,int,double const*,int,int,int,int,int,unsigned int)
  ** @see ::vl_imconvcoltri_vf()
- **/
+ **/

vl/imopv.h

@@ -13,7 +13,7 @@
 #define VL_PAD_BY_ZERO       (0x0 << 0) /**< @brief Pad with zeroes. */
 #define VL_PAD_BY_CONTINUITY (0x1 << 0) /**< @brief Pad by continuity. */
 #define VL_PAD_MASK          (0x3)      /**< @brief Padding field selector. */
-#define VL_TRANSPOSE         (0x1 << 2) /**< @brief Traspose result. */
+#define VL_TRANSPOSE         (0x1 << 2) /**< @brief Transpose result. */
 /** @} */
 
 /** @name Image convolution