Fixing all wrong uses of RGB channels instead of the OpenCV BGR standard

doc/tutorials/core/basic_geometric_drawing/basic_geometric_drawing.rst

@@ -44,14 +44,14 @@ or
 Scalar
 -------
 * Represents a 4-element vector. The type Scalar is widely used in OpenCV for passing pixel values.
-* In this tutorial, we will use it extensively to represent RGB color values (3 parameters). It is not necessary to define the last argument if it is not going to be used.
+* In this tutorial, we will use it extensively to represent BGR color values (3 parameters). It is not necessary to define the last argument if it is not going to be used.
 * Let's see an example, if we are asked for a color argument and we give:
 
   .. code-block:: cpp
 
      Scalar( a, b, c )
 
-  We would be defining a RGB color such as: *Red = c*, *Green = b* and *Blue = a*
+  We would be defining a BGR color such as: *Blue = a*, *Green = b* and *Red = c*
 
 
 Code
@@ -135,7 +135,7 @@ Explanation
 
         * Draw a line from Point **start** to Point **end**
         * The line is displayed in the image **img**
-        * The line color is defined by **Scalar( 0, 0, 0)** which is the RGB value correspondent to **Black**
+        * The line color is defined by **Scalar( 0, 0, 0)** which is the BGR value correspondent to **Black**
         * The line thickness is set to **thickness** (in this case 2)
         * The line is a 8-connected one (**lineType** = 8)
 
@@ -167,7 +167,7 @@ Explanation
         * The ellipse center is located in the point **(w/2.0, w/2.0)** and is enclosed in a box of size **(w/4.0, w/16.0)**
         * The ellipse is rotated **angle** degrees
         * The ellipse extends an arc between **0** and **360** degrees
-        * The color of the figure will be **Scalar( 255, 255, 0)** which means blue in RGB value.
+        * The color of the figure will be **Scalar( 255, 0, 0)** which means blue in BGR value.
         * The ellipse's **thickness** is 2.
 
 

doc/tutorials/core/basic_linear_transform/basic_linear_transform.rst

@@ -151,7 +151,7 @@ Explanation
 
    We observe that :mat_zeros:`Mat::zeros <>` returns a Matlab-style zero initializer based on *image.size()* and *image.type()*
 
-#. Now, to perform the operation :math:`g(i,j) = \alpha \cdot f(i,j) + \beta` we will access to each pixel in image. Since we are operating with RGB images, we will have three values per pixel (R, G and B), so we will also access them separately. Here is the piece of code:
+#. Now, to perform the operation :math:`g(i,j) = \alpha \cdot f(i,j) + \beta` we will access to each pixel in image. Since we are operating with BGR images, we will have three values per pixel (B, G and R), so we will also access them separately. Here is the piece of code:
 
    .. code-block:: cpp
 

doc/tutorials/core/how_to_scan_images/how_to_scan_images.rst

@@ -40,7 +40,7 @@ You can download the full source code :download:`here <../../../../samples/cpp/t
 
    how_to_scan_images imageName.jpg intValueToReduce [G]
 
-The final argument is optional. If given the image will be loaded in gray scale format, otherwise the RGB color way is used. The first thing is to calculate the lookup table.
+The final argument is optional. If given the image will be loaded in gray scale format, otherwise the BGR color way is used. The first thing is to calculate the lookup table.
 
 .. literalinclude:: ../../../../samples/cpp/tutorial_code/core/how_to_scan_images/how_to_scan_images.cpp
    :language: cpp
@@ -76,7 +76,7 @@ As you could already read in my :ref:`matTheBasicImageContainer` tutorial the si
    Row n & \tabItG{n,0} & \tabItG{n,1} & \tabItG{n,...} & \tabItG{n, m} \\
    \end{tabular}
 
-For multichannel images the columns contain as many sub columns as the number of channels. For example in case of an RGB color system:
+For multichannel images the columns contain as many sub columns as the number of channels. For example in case of an BGR color system:
 
 .. math::
 
@@ -89,7 +89,7 @@ For multichannel images the columns contain as many sub columns as the number of
    Row n & \tabIt{n,0} & \tabIt{n,1} & \tabIt{n,...} & \tabIt{n, m} \\
    \end{tabular}
 
-Note that the order of the channels is inverse: BGR instead of RGB. Because in many cases the memory is large enough to store the rows in a successive fashion the rows may follow one after another, creating a single long row. Because everything is in a single place following one after another this may help to speed up the scanning process. We can use the :basicstructures:`isContinuous() <mat-iscontinuous>` function to *ask* the matrix if this is the case. Continue on to the next section to find an example.
+Because in many cases the memory is large enough to store the rows in a successive fashion the rows may follow one after another, creating a single long row. Because everything is in a single place following one after another this may help to speed up the scanning process. We can use the :basicstructures:`isContinuous() <mat-iscontinuous>` function to *ask* the matrix if this is the case. Continue on to the next section to find an example.
 
 The efficient way
 =================

doc/tutorials/core/interoperability_with_OpenCV_1/interoperability_with_OpenCV_1.rst

@@ -87,7 +87,7 @@ Here you can observe that with the new structure we have no pointer problems, al
    :tab-width: 4
    :lines: 46-51
 
-Because, we want to mess around with the images luma component we first convert from the default RGB to the YUV color space and then split the result up into separate planes. Here the program splits: in the first example it processes each plane using one of the three major image scanning algorithms in OpenCV (C [] operator, iterator, individual element access). In a second variant we add to the image some Gaussian noise and then mix together the channels according to some formula.
+Because, we want to mess around with the images luma component we first convert from the default BGR to the YUV color space and then split the result up into separate planes. Here the program splits: in the first example it processes each plane using one of the three major image scanning algorithms in OpenCV (C [] operator, iterator, individual element access). In a second variant we add to the image some Gaussian noise and then mix together the channels according to some formula.
 
 The scanning version looks like:
 

doc/tutorials/core/mat_the_basic_image_container/mat_the_basic_image_container.rst

@@ -76,12 +76,12 @@ There are, however, many other color systems each with their own advantages:
 
 .. container:: enumeratevisibleitemswithsquare
 
-   * RGB is the most common as our eyes use something similar, our display systems also compose colors using these.
+   * RGB is the most common as our eyes use something similar, but keep in mind that the OpenCV display system uses BGR colors.
    * The HSV and HLS decompose colors into their hue, saturation and value/luminance components, which is a more natural way for us to describe colors.  You might, for example, dismiss the value component, making your algorithm less sensitive to the light conditions of the input image.
    * YCrCb is used by the popular JPEG image format.
    * CIE L*a*b* is a perceptually uniform color space, which comes handy if you need to measure the *distance* of a given color to another color.
 
-Each of the color components has its own valid domains. This brings us to the data type used: how we store a component defines the control we have over its domain. The smallest data type possible is *char*, which means one byte or 8 bits. This may be unsigned (so can store values from 0 to 255) or signed (values from -127 to +127). Although in the case of three components (such as RGB) this already gives 16 million representable colors. We may acquire an even finer control by using the float (4 byte = 32 bit) or double (8 byte = 64 bit) data types for each component. Nevertheless, remember that increasing the size of a component also increases the size of the whole picture in the memory.
+Each of the color components has its own valid domains. This brings us to the data type used: how we store a component defines the control we have over its domain. The smallest data type possible is *char*, which means one byte or 8 bits. This may be unsigned (so can store values from 0 to 255) or signed (values from -127 to +127). Although in the case of three components (such as BGR) this already gives 16 million representable colors. We may acquire an even finer control by using the float (4 byte = 32 bit) or double (8 byte = 64 bit) data types for each component. Nevertheless, remember that increasing the size of a component also increases the size of the whole picture in the memory.
 
 Creating a *Mat* object explicitly
 ==================================