diff --git a/doc/tutorials/contrib/retina_model/retina_model.rst b/doc/tutorials/contrib/retina_model/retina_model.rst index 313e3bc12..852b9e61e 100644 --- a/doc/tutorials/contrib/retina_model/retina_model.rst +++ b/doc/tutorials/contrib/retina_model/retina_model.rst @@ -193,7 +193,7 @@ In the main program, before processing, first check input command parameters. He { std::cout<<"RetinaDemo: processing image "<` 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 diff --git a/doc/tutorials/core/how_to_scan_images/how_to_scan_images.rst b/doc/tutorials/core/how_to_scan_images/how_to_scan_images.rst index b6a18fee8..b2ee519c1 100644 --- a/doc/tutorials/core/how_to_scan_images/how_to_scan_images.rst +++ b/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() ` 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() ` function to *ask* the matrix if this is the case. Continue on to the next section to find an example. The efficient way ================= diff --git a/doc/tutorials/core/interoperability_with_OpenCV_1/interoperability_with_OpenCV_1.rst b/doc/tutorials/core/interoperability_with_OpenCV_1/interoperability_with_OpenCV_1.rst index 62afaed49..6cfe9fb54 100644 --- a/doc/tutorials/core/interoperability_with_OpenCV_1/interoperability_with_OpenCV_1.rst +++ b/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: diff --git a/doc/tutorials/core/mat_the_basic_image_container/mat_the_basic_image_container.rst b/doc/tutorials/core/mat_the_basic_image_container/mat_the_basic_image_container.rst index e93d33884..b45636114 100644 --- a/doc/tutorials/core/mat_the_basic_image_container/mat_the_basic_image_container.rst +++ b/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 ================================== diff --git a/doc/tutorials/highgui/video-write/video-write.rst b/doc/tutorials/highgui/video-write/video-write.rst index 16be92bbe..a0987021d 100644 --- a/doc/tutorials/highgui/video-write/video-write.rst +++ b/doc/tutorials/highgui/video-write/video-write.rst @@ -14,7 +14,7 @@ Whenever you work with video feeds you may eventually want to save your image pr + What type of video files you can create with OpenCV + How to extract a given color channel from a video -As a simple demonstration I'll just extract one of the RGB color channels of an input video file into a new video. You can control the flow of the application from its console line arguments: +As a simple demonstration I'll just extract one of the BGR color channels of an input video file into a new video. You can control the flow of the application from its console line arguments: .. container:: enumeratevisibleitemswithsquare @@ -111,7 +111,7 @@ Afterwards, you use the :hgvideo:`isOpened() ` function to outputVideo.write(res); //or outputVideo << res; -Extracting a color channel from an RGB image means to set to zero the RGB values of the other channels. You can either do this with image scanning operations or by using the split and merge operations. You first split the channels up into different images, set the other channels to zero images of the same size and type and finally merge them back: +Extracting a color channel from an BGR image means to set to zero the BGR values of the other channels. You can either do this with image scanning operations or by using the split and merge operations. You first split the channels up into different images, set the other channels to zero images of the same size and type and finally merge them back: .. code-block:: cpp diff --git a/doc/tutorials/imgproc/erosion_dilatation/erosion_dilatation.rst b/doc/tutorials/imgproc/erosion_dilatation/erosion_dilatation.rst index 39bac9e6d..64f80e4aa 100644 --- a/doc/tutorials/imgproc/erosion_dilatation/erosion_dilatation.rst +++ b/doc/tutorials/imgproc/erosion_dilatation/erosion_dilatation.rst @@ -177,7 +177,7 @@ Explanation .. container:: enumeratevisibleitemswithsquare - * Load an image (can be RGB or grayscale) + * Load an image (can be BGR or grayscale) * Create two windows (one for dilation output, the other for erosion) * Create a set of 02 Trackbars for each operation: diff --git a/doc/tutorials/imgproc/histograms/histogram_comparison/histogram_comparison.rst b/doc/tutorials/imgproc/histograms/histogram_comparison/histogram_comparison.rst index f5f636d08..5eb72d64d 100644 --- a/doc/tutorials/imgproc/histograms/histogram_comparison/histogram_comparison.rst +++ b/doc/tutorials/imgproc/histograms/histogram_comparison/histogram_comparison.rst @@ -93,7 +93,7 @@ Code Explanation =========== -#. Declare variables such as the matrices to store the base image and the two other images to compare ( RGB and HSV ) +#. Declare variables such as the matrices to store the base image and the two other images to compare ( BGR and HSV ) .. code-block:: cpp diff --git a/doc/tutorials/imgproc/imgtrans/laplace_operator/laplace_operator.rst b/doc/tutorials/imgproc/imgtrans/laplace_operator/laplace_operator.rst index c54df27d6..c83dcc6b1 100644 --- a/doc/tutorials/imgproc/imgtrans/laplace_operator/laplace_operator.rst +++ b/doc/tutorials/imgproc/imgtrans/laplace_operator/laplace_operator.rst @@ -88,7 +88,7 @@ Code GaussianBlur( src, src, Size(3,3), 0, 0, BORDER_DEFAULT ); /// Convert the image to grayscale - cvtColor( src, src_gray, CV_RGB2GRAY ); + cvtColor( src, src_gray, CV_BGR2GRAY ); /// Create window namedWindow( window_name, CV_WINDOW_AUTOSIZE ); @@ -141,7 +141,7 @@ Explanation .. code-block:: cpp - cvtColor( src, src_gray, CV_RGB2GRAY ); + cvtColor( src, src_gray, CV_BGR2GRAY ); #. Apply the Laplacian operator to the grayscale image: diff --git a/doc/tutorials/imgproc/imgtrans/sobel_derivatives/sobel_derivatives.rst b/doc/tutorials/imgproc/imgtrans/sobel_derivatives/sobel_derivatives.rst index f4eb96e7c..8d06c81bc 100644 --- a/doc/tutorials/imgproc/imgtrans/sobel_derivatives/sobel_derivatives.rst +++ b/doc/tutorials/imgproc/imgtrans/sobel_derivatives/sobel_derivatives.rst @@ -154,7 +154,7 @@ Code GaussianBlur( src, src, Size(3,3), 0, 0, BORDER_DEFAULT ); /// Convert it to gray - cvtColor( src, src_gray, CV_RGB2GRAY ); + cvtColor( src, src_gray, CV_BGR2GRAY ); /// Create window namedWindow( window_name, CV_WINDOW_AUTOSIZE ); @@ -217,7 +217,7 @@ Explanation .. code-block:: cpp - cvtColor( src, src_gray, CV_RGB2GRAY ); + cvtColor( src, src_gray, CV_BGR2GRAY ); #. Second, we calculate the "*derivatives*" in *x* and *y* directions. For this, we use the function :sobel:`Sobel <>` as shown below: diff --git a/doc/tutorials/imgproc/threshold/threshold.rst b/doc/tutorials/imgproc/threshold/threshold.rst index a264fd110..4f7ab9267 100644 --- a/doc/tutorials/imgproc/threshold/threshold.rst +++ b/doc/tutorials/imgproc/threshold/threshold.rst @@ -167,7 +167,7 @@ The tutorial code's is shown lines below. You can also download it from `here `: + * Load an image. If it is BGR we convert it to Grayscale. For this, remember that we can use the function :cvt_color:`cvtColor <>`: .. code-block:: cpp src = imread( argv[1], 1 ); /// Convert the image to Gray - cvtColor( src, src_gray, CV_RGB2GRAY ); + cvtColor( src, src_gray, CV_BGR2GRAY ); * Create a window to display the result diff --git a/doc/tutorials/introduction/display_image/display_image.rst b/doc/tutorials/introduction/display_image/display_image.rst index 40a66a54e..9e8081813 100644 --- a/doc/tutorials/introduction/display_image/display_image.rst +++ b/doc/tutorials/introduction/display_image/display_image.rst @@ -68,7 +68,7 @@ Now we call the :imread:`imread <>` function which loads the image name specifie + CV_LOAD_IMAGE_UNCHANGED (<0) loads the image as is (including the alpha channel if present) + CV_LOAD_IMAGE_GRAYSCALE ( 0) loads the image as an intensity one - + CV_LOAD_IMAGE_COLOR (>0) loads the image in the RGB format + + CV_LOAD_IMAGE_COLOR (>0) loads the image in the BGR format .. literalinclude:: ../../../../samples/cpp/tutorial_code/introduction/display_image/display_image.cpp :language: cpp diff --git a/doc/tutorials/introduction/load_save_image/load_save_image.rst b/doc/tutorials/introduction/load_save_image/load_save_image.rst index 6f8150a00..bb7758341 100644 --- a/doc/tutorials/introduction/load_save_image/load_save_image.rst +++ b/doc/tutorials/introduction/load_save_image/load_save_image.rst @@ -63,7 +63,7 @@ Here it is: Explanation ============ -#. We begin by loading an image using :readwriteimagevideo:`imread `, located in the path given by *imageName*. For this example, assume you are loading a RGB image. +#. We begin by loading an image using :readwriteimagevideo:`imread `, located in the path given by *imageName*. For this example, assume you are loading a BGR image. #. Now we are going to convert our image from BGR to Grayscale format. OpenCV has a really nice function to do this kind of transformations: diff --git a/doc/user_guide/ug_intelperc.rst b/doc/user_guide/ug_intelperc.rst index bc4cd325e..f08d8f2c6 100644 --- a/doc/user_guide/ug_intelperc.rst +++ b/doc/user_guide/ug_intelperc.rst @@ -7,7 +7,7 @@ Senz3D and Intel Perceptual Computing SDK Using Creative Senz3D and other Intel Perceptual Computing SDK compatible depth sensors ======================================================================================= -Depth sensors compatible with Intel Perceptual Computing SDK are supported through ``VideoCapture`` class. Depth map, RGB image and some other formats of output can be retrieved by using familiar interface of ``VideoCapture``. +Depth sensors compatible with Intel Perceptual Computing SDK are supported through ``VideoCapture`` class. Depth map, BGR image and some other formats of output can be retrieved by using familiar interface of ``VideoCapture``. In order to use depth sensor with OpenCV you should do the following preliminary steps: @@ -28,7 +28,7 @@ VideoCapture can retrieve the following data: * ``CV_CAP_INTELPERC_UVDEPTH_MAP`` - each pixel contains two 32-bit floating point values in the range of 0-1, representing the mapping of depth coordinates to the color coordinates. (CV_32FC2) * ``CV_CAP_INTELPERC_IR_MAP`` - each pixel is a 16-bit integer. The value indicates the intensity of the reflected laser beam. (CV_16UC1) #. - data given from RGB image generator: + data given from BGR image generator: * ``CV_CAP_INTELPERC_IMAGE`` - color image. (CV_8UC3) In order to get depth map from depth sensor use ``VideoCapture::operator >>``, e. g. :: @@ -76,4 +76,4 @@ Since two types of sensor's data generators are supported (image generator and d For more information please refer to the example of usage intelperc_capture.cpp_ in ``opencv/samples/cpp`` folder. -.. _intelperc_capture.cpp: https://github.com/Itseez/opencv/tree/master/samples/cpp/intelperc_capture.cpp \ No newline at end of file +.. _intelperc_capture.cpp: https://github.com/Itseez/opencv/tree/master/samples/cpp/intelperc_capture.cpp diff --git a/doc/user_guide/ug_kinect.rst b/doc/user_guide/ug_kinect.rst index 5bbdfee48..cb15ac42d 100644 --- a/doc/user_guide/ug_kinect.rst +++ b/doc/user_guide/ug_kinect.rst @@ -7,7 +7,7 @@ Kinect and OpenNI Using Kinect and other OpenNI compatible depth sensors ====================================================== -Depth sensors compatible with OpenNI (Kinect, XtionPRO, ...) are supported through ``VideoCapture`` class. Depth map, RGB image and some other formats of output can be retrieved by using familiar interface of ``VideoCapture``. +Depth sensors compatible with OpenNI (Kinect, XtionPRO, ...) are supported through ``VideoCapture`` class. Depth map, BGR image and some other formats of output can be retrieved by using familiar interface of ``VideoCapture``. In order to use depth sensor with OpenCV you should do the following preliminary steps: @@ -47,7 +47,7 @@ VideoCapture can retrieve the following data: * ``CV_CAP_OPENNI_DISPARITY_MAP_32F`` - disparity in pixels (CV_32FC1) * ``CV_CAP_OPENNI_VALID_DEPTH_MASK`` - mask of valid pixels (not ocluded, not shaded etc.) (CV_8UC1) #. - data given from RGB image generator: + data given from BGR image generator: * ``CV_CAP_OPENNI_BGR_IMAGE`` - color image (CV_8UC3) * ``CV_CAP_OPENNI_GRAY_IMAGE`` - gray image (CV_8UC1) @@ -69,7 +69,7 @@ For getting several data maps use ``VideoCapture::grab`` and ``VideoCapture::ret for(;;) { Mat depthMap; - Mat rgbImage + Mat bgrImage; capture.grab();