Android 4.3 support added;
ANY camera index support fixed;
applyProperties now uses camera->reconnect() instead close/connect for Android 4.x.
(cherry picked from commit fff91eef0b)
- set init value for `numsdev` to prevent use of uninitialized value
- stop use of 'workdir' and files from samples
- forcing use of 'opencv_extra' instead
Note: set OPENCV_TEST_DATA_PATH to full path to 'opencv_extra/testdata' (gitolite@code.opencv.org:opencv_extra.git) before running the test!
[NSRunLoop currentRunLoop] is not the same as in the main thread.
see
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/F
oundation/Classes/nsrunloop_Class/Reference/Reference.html
"If no input sources or timers are attached to the run loop, this
method exits immediately"
The old code caused grabFrame() to return immediately if the capture
was not done in the main thread.
This code works correctly, even in secondary threads, provided that all
capture functions are called in the *same* thread
Previously the function requires Info::Impl implicitly. A call will create
new Context this function which is not intended.
The properties are now moved to global scope to fix this issue.
Video i/o tests enabled for media foundation;
Negative stride support added to VideoCapture;
Error handling improved, dead lock in case of playback error fixed;
Some code refacotring done.
Now it can determine, without looking at the file name, both the module
name and the configuration name (the latter with a little help from the
configuration file).
* In comparison column headers, switched the order of labels, so that
it's "to" vs "from".
* When a test was present, but not run successfully, put its status in
the corresponding cell instead of coloring it gray.
OPENCLAMDBLAS and OPENCLAMDFFT never detected under linux.
lib64/import and lib32/import is the path on Windows but not Linux.
for CLAMDBLAS library we should use CLAMDBLAS_PATH (not CLAMDFFT_PATH)
Previously the feature is controlled by setBinpath implicitly.
We add the function to cope with setBinpath and setBinpath is only
useful when setBinaryDiskCache is set.
Refer to the header to see more info.
changed line281 -> line220
Presentation:
because line 220 give the globle var mDetectorType,and in line 230 it will be compared with mDeteorType !!! it will never be unequal ~
fix:
change mDetectorType(previous globle var) to a new local val tmpDetectorType
When user provided corners buffer is big enough to be copied to from
tmpCorners_, we allow the buffer to be reused other than allocate a new
cl_mem object.
Added for better compatibility with the current samples/test cases.
User now will be able to initialize OpenCL context explicitly with
ocl::getDevice api.
This may be obsoleted in future releases.
Yes, it's as ludicrous as it sounds, but it's still true. Bizarrely,
the previous commit makes CLAHE run about 10% slower on Android, even
though it doesn't even touch any CLAHE code. Splitting it off fixes that,
although the reason it does is a mystery for the ages.
It's cleaner when it's in its own file, anyway. ;=]
The new sample adjust some parameters thus it should always be able to
calculate valid homography matrix when input is box.png and
box_in_scene.png.
Pure cpp surf and bfmatcher implementation is also added to show the user
its accuracy and performance.
For example, haarcascade_frontalface_alt2.xml is now supported.
Note that classifier's pattern of a cascade file must be consistent,
i.e., all trees must either have two nodes or one node, otherwise
unexpected results will occur.
Other fixes:
Test cases are updated.
Some unused codes are removed.
Fix some problems of haar when using OclCascadeClassifierBuf.
This fix is a workaround for current 2.4 branch without introducing an
additional oclMat buffer into CannyBuf object.
Test case is cleaned up.
Volatile keywords in kernels are removed for performance concern.
When argument pointers pushed into an vector and the pointers point to
address on stack, we need to make sure they are valid until kernels are
successfully flushed onto the queue.
I've moved the contents of CONTRIBUTING.md to the wiki (and slightly
expanded it), so the former is no longer required. I've put a link to the
wiki page and a summary in the README.
Additional notes with this commit:
1. Add cornerHarris_dxdy and cornerMinEigenVal_dxdy to get
the interim dx and dy output of Sobel operator;
2. Add minMax_buf to allow user to reuse buffers in minMax;
3. Fix an error when either min or max pointer fed into minMax is NULL;
4. Corner sorter temporarily uses C++ STL's quick sort. A parallel
selection sort in OpneCL is contained in the implementation but disabled
due to poor performance at the moment.
5. Accuracy test for ocl gfft.
Use predefined OpenCL function to convert integers to floating points.
This is more accurate than before as it enables:
1. saturate cast
2. customized rounding
A modification of the JavaCameraView is needed to avoid a crash when the
app is exited. It is a good practice to remove the callback after the
stopPreview method.
The orientation of convexHull's result is currently the opposite of what the
documentation would suggest:
>>> import cv2, numpy as np
>>> points = np.array([[0,0],[0,1],[1,0]], dtype=np.int32)
>>> cv2.convexHull(points, clockwise=False)
array([[[1, 0]],
[[0, 1]],
[[0, 0]]], dtype=int32)
>>> cv2.convexHull(points, clockwise=True)
array([[[0, 0]],
[[0, 1]],
[[1, 0]]], dtype=int32)
Changing the function itself is probably not a good idea at this point, so
this fixes the documentation by flipping the coordinate system.
I also removed the mention of the origin, since it's irrelevant for this
function.
Mac OS X 10.7 and newer don't come with Java installed. They do
include some stub binaries, which ask the user if they want to
install Java when run.
OpenCV's cmake script just checks for the existence of an ant
binary and assumes that Java's available if ant is. As a result,
cmake will configure the build to use Java and it will fail once
it tries to compile the Java bindings.
This fixes the issue by checking for the exit status of
`ant -version` - it exits 0 if Java is installed, or 1
otherwise.(cherry picked from commit a423afddc1)
The generated OpenCV Java source can contain characters outside of ASCII on some systems – this patch allows the ant task to compile them.
(cherry picked from commit f3ee55e042)
1. Added more sync to reduction.
2. Turned off Image2D feature. Probably its support is not detected correctly.
3. Temporary disabled descriptor tests - can't localize a problem of the ocl descriptor.
The test cases are ported from gpu module (masked version is still
missing).
Key point direction definition is synchronized with cv::SURF.
nonfree module dependency is added into ocl module's cmake file.
* fix path to libraries in Android SDK
* allow to link to opencv_java.so as Android.mk does
To link to opencv_java.so you can either change your cmake to find OpenCV as
find_package(OpenCV opencv_java)
or pass -DOpenCV_FIND_COMPONENTS=opencv_java to your cmake command
Legend for new column is:
* FASTER - strong speedup
* faster - spedup is detected but it is unreliable
* <empty> - no change in speed
* slower - slowdown is detected but it is unreliable
* SLOWER - strong slowdown
- libavcodec issue
- some decoders alter AVCodecContext width/height values, in a wrong way
- eg. in issue 2815, vp6f decoder changes these values, resulting in distorted / invalid frames
- this patch forces default AVCodecContext values
range in calcHist() changed from [0,255] to [0,256]. Otherwise, it won't count pixels with value 255. It can be verified taking sum of histogram values and checking it with image size.
* removed OpenGLFuncTab, now extensions are loaded internally
* added support of GlBuffer and GlTexture2D to InputArray/OutputArray
* added ELEMENT_ARRAY_BUFFER and PIXEL_PACK_BUFFER targets
* added copyFrom/copyTo method for GlBuffer and GlTexture2D
* removed GlFont
* removed pointCloudShow
* removed OpenGLCleanCallback
* added Access parameter to GlBuffer::mapHost
* added autoRelease parameter to all create methods
Made changes to work in cv::Algorithm with parameters of these types.
Also fixed SimpleBlobDetector -- now it can be created by
cv::Algorithm::create and it can work with cv::Algorithm::set/get.
Use min/max bounds instead of local value to calculate acceptance threshold.
Threshold based on local values somethimes does not work because cancellation
of big values may produce error bigger than local value.
Tutorial text was not consistent with tutorial source code in samples directory.
Inline source code was replaced on "includeliteral" directive with link to cpp file.
modified SIFT to 1) double image before finding keypoints, 2) use floating-point internally instead of 16-bit integers, 3) set the keypoint response to the abs(interpolated_DoG_value). step 1) increases the number of detected keypoints significantly and together with 2) and 3) it improves some detection benchmarks. On the other hand, the stability of the small keypoints is lower, so the rotation and scale invariance tests now struggle a bit. In 2.5 need to make this feature optional and add some more intelligence to the algorithm.
added test that finds a planar object using SIFT.
* Decouple Video4Linux2 support from Video4Linux as existence of
v4l2 on a system does not imply support for v4l.
* Don't use V4L's struct video_window in V4L2 code.
* Removed __USE_GNU as comment says:
/* support for MJPEG is only available with libjpeg and gcc,
because it's use libjepg and fmemopen()
so replace with test for fmemopen() if found necessary.
The video(4) driver provides a Video4Linux2 compatible API for
various video peripherals. This patch propagates HAVE_VIDEOIO if
the sys/videoio.h include file is found, which is the signature of
video(4).
Fixed visualization by choosing the color appropriate to the detection
score.
Previously the example showed all detections with the same color
disregarding the confidence. This led to the impression that the object
detection did not work at all because there are many detections with low
confidences.
PR to master was
https://github.com/Itseez/opencv/pull/320
- new reduce implementation (with kepler optimizations)
- saturate_cast via asm command
- video SIMD instructions in element operations
- float arithmetics instead of double
- new deviceSupports function
- fixed printCudaDeviceInfo for new CC
- fixed some compilation errors and warnings
- removed unset command from CMake script
- removed unused std imports
Sometimes information about dependencies causing disabling were loosed and it
was not possible to correctly display these dependencies in status report
OCV_OPTION(WITH_AVFOUNDATION"Use AVFoundation for Video I/O"ONIFIOS)
OCV_OPTION(WITH_CARBON"Use Carbon for UI instead of Cocoa"OFFIFAPPLE)
OCV_OPTION(WITH_CUBLAS"Include NVidia Cuda Basic Linear Algebra Subprograms (BLAS) library support"OFFIF(CMAKE_VERSIONVERSION_GREATER"2.8"ANDNOTANDROIDANDNOTIOS))
OCV_OPTION(WITH_CUDA"Include NVidia Cuda Runtime support"ONIF(CMAKE_VERSIONVERSION_GREATER"2.8"ANDNOTANDROIDANDNOTIOS))
OCV_OPTION(WITH_CUFFT"Include NVidia Cuda Fast Fourier Transform (FFT) library support"ONIF(CMAKE_VERSIONVERSION_GREATER"2.8"ANDNOTANDROIDANDNOTIOS))
OCV_OPTION(WITH_CUBLAS"Include NVidia Cuda Basic Linear Algebra Subprograms (BLAS) library support"OFFIF(CMAKE_VERSIONVERSION_GREATER"2.8"ANDNOTANDROIDANDNOTIOS))
OCV_OPTION(WITH_NVCUVID"Include NVidia Video Decoding library support"OFFIF(CMAKE_VERSIONVERSION_GREATER"2.8"ANDNOTANDROIDANDNOTIOSANDNOTAPPLE))
OCV_OPTION(ENABLE_SOLUTION_FOLDERS"Solution folder in Visual Studio or in other IDEs"(MSVC_IDEORCMAKE_GENERATORMATCHESXcode)IF(CMAKE_VERSIONVERSION_GREATER"2.8.0"))
OCV_OPTION(ENABLE_PROFILING"Enable profiling in the GCC compiler (Add flags: -g -pg)"OFFIFCMAKE_COMPILER_IS_GNUCXX)
OCV_OPTION(ENABLE_OMIT_FRAME_POINTER"Enable -fomit-frame-pointer for GCC"ONIFCMAKE_COMPILER_IS_GNUCXX)
OCV_OPTION(ENABLE_OMIT_FRAME_POINTER"Enable -fomit-frame-pointer for GCC"ONIFCMAKE_COMPILER_IS_GNUCXXANDNOT(APPLEANDCMAKE_COMPILER_IS_CLANGCXX))
OCV_OPTION(ENABLE_POWERPC"Enable PowerPC for GCC"ONIF(CMAKE_COMPILER_IS_GNUCXXANDCMAKE_SYSTEM_PROCESSORMATCHESpowerpc.*))
OCV_OPTION(ENABLE_FAST_MATH"Enable -ffast-math (not recommended for GCC 4.6.x)"OFFIF(CMAKE_COMPILER_IS_GNUCXXAND(X86ORX86_64)))
set(HAVE_${__modname}OFFCACHEINTERNAL"Module ${__modname} can not be built in current configuration")
set(OPENCV_MODULE_${__modname}_LOCATION"${CMAKE_CURRENT_SOURCE_DIR}"CACHEINTERNAL"Location of ${__modname} module sources")
set(OPENCV_MODULES_DISABLED_FORCE"${OPENCV_MODULES_DISABLED_FORCE}"CACHEINTERNAL"List of OpenCV modules which can not be build in current configuration")
if(BUILD_${__modname})
# touch variable controlling build of the module to suppress "unused variable" CMake warning
message(FATAL_ERROR "OpenCV static library compiled with CUDA ${OpenCV_CUDA_VERSION} support. Please, use the same version or rebuild OpenCV with CUDA ${CUDA_VERSION_STRING}")
message(FATAL_ERROR "OpenCV static library was compiled with CUDA ${OpenCV_CUDA_VERSION} support. Please, use the same version or rebuild OpenCV with CUDA ${CUDA_VERSION_STRING}")
So for an old pixel point at :math:`(x,y)` coordinate in the input image, for a corrected output image its position will be :math:`(x_{corrected} y_{corrected})` . The presence of the radial distortion manifests in form of the "barrel" or "fish-eye" effect.
We have multiple ways to acquire digital images from the real world: digital cameras, scanners, computed tomography or magnetic resonance imaging to just name a few. In every case what we (humans) see are images. However, when transforming this to our digital devices what we record are numerical values for each of the points of the image.
We have multiple ways to acquire digital images from the real world: digital cameras, scanners, computed tomography, and magnetic resonance imaging to name a few. In every case what we (humans) see are images. However, when transforming this to our digital devices what we record are numerical values for each of the points of the image.
..image:: images/MatBasicImageForComputer.jpg
:alt:A matrix of the mirror of a car
:align:center
For example in the above image you can see that the mirror of the care is nothing more than a matrix containing all the intensity values of the pixel points. Now, how we get and store the pixels values may vary according to what fits best our need, in the end all images inside a computer world may be reduced to numerical matrices and some other information's describing the matric itself. *OpenCV* is a computer vision library whose main focus is to process and manipulate these information to find out further ones. Therefore, the first thing you need to learn and get accommodated with is how OpenCV stores and handles images.
For example in the above image you can see that the mirror of the car is nothing more than a matrix containing all the intensity values of the pixel points. How we get and store the pixels values may vary according to our needs, but in the end all images inside a computer world may be reduced to numerical matrices and other information describing the matrix itself. *OpenCV* is a computer vision library whose main focus is to process and manipulate this information. Therefore, the first thing you need to be familiar with is how OpenCV stores and handles images.
*Mat*
=====
OpenCV has been around ever since 2001. In those days the library was built around a *C* interface. In those days to store the image in the memory they used a C structure entitled *IplImage*. This is the one you'll see in most of the older tutorials and educational materials. The problem with this is that it brings to the table all the minuses of the C language. The biggest issue is the manual management. It builds on the assumption that the user is responsible for taking care of memory allocation and deallocation. While this is no issue in case of smaller programs once your code base start to grove larger and larger it will be more and more a struggle to handle all this rather than focusing on actually solving your development goal.
OpenCV has been around since 2001. In those days the library was built around a *C* interface and to store the image in the memory they used a C structure called *IplImage*. This is the one you'll see in most of the older tutorials and educational materials. The problem with this is that it brings to the table all the minuses of the C language. The biggest issue is the manual memory management. It builds on the assumption that the user is responsible for taking care of memory allocation and deallocation. While this is not a problem with smaller programs, once your code base grows it will be more of a struggle to handle all this rather than focusing on solving your development goal.
Luckily C++ came around and introduced the concept of classes making possible to build another road for the user: automatic memory management (more or less). The good news is that C++ if fully compatible with C so no compatibility issues can arise from making the change. Therefore, OpenCV with its 2.0 version introduced a new C++ interface that by taking advantage of these offers a new way of doing things. A way, in which you do not need to fiddle with memory management; making your code concise (less to write, to achieve more). The only main downside of the C++ interface is that many embedded development systems at the moment support only C. Therefore, unless you are targeting this platform, there's no point on using the *old* methods (unless you're a masochist programmer and you're asking for trouble).
Luckily C++ came around and introduced the concept of classes making easier for the user through automatic memory management (more or less). The good news is that C++ is fully compatible with C so no compatibility issues can arise from making the change. Therefore, OpenCV 2.0 introduced a new C++ interface which offered a new way of doing things which means you do not need to fiddle with memory management, making your code concise (less to write, to achieve more). The main downside of the C++ interface is that many embedded development systems at the moment support only C. Therefore, unless you are targeting embedded platforms, there's no point to using the *old* methods (unless you're a masochist programmer and you're asking for trouble).
The first thing you need to know about *Mat* is that you no longer need to manually allocate its size and release it as soon as you do not need it. While doing this is still a possibility, most of the OpenCV functions will allocate its output data manually. As a nice bonus if you pass on an already existing *Mat* object, what already has allocated the required space for the matrix, this will be reused. In other words we use at all times only as much memory as much we must to perform the task.
The first thing you need to know about *Mat* is that you no longer need to manually allocate its memory and release it as soon as you do not need it. While doing this is still a possibility, most of the OpenCV functions will allocate its output data manually. As a nice bonus if you pass on an already existing *Mat* object, which has already allocated the required space for the matrix, this will be reused. In other words we use at all times only as much memory as we need to perform the task.
*Mat* is basically a class having two data parts: the matrix header (containing information such as the size of the matrix, the method used for storing, at which address is the matrix stored and so on) and a pointer to the matrix containing the pixel values (may take any dimensionality depending on the method chosen for storing) . The matrix header size is constant. However, the size of the matrix itself may vary from image to image and usually is larger by order of magnitudes. Therefore, when you're passing on images in your program and at some point you need to create a copy of the image the big price you will need to build is for the matrix itself rather than its header. OpenCV is an image processing library. It contains a large collection of image processing functions. To solve a computational challenge most of the time you will end up using multiple functions of the library. Due to this passing on images to functions is a common practice. We should not forget that we are talking about image processing algorithms, which tend to be quite computational heavy. The last thing we want to do is to further decrease the speed of your program by making unnecessary copies of potentially *large* images.
*Mat* is basically a class with two data parts: the matrix header (containing information such as the size of the matrix, the method used for storing, at which address is the matrix stored, and so on) and a pointer to the matrix containing the pixel values (taking any dimensionality depending on the method chosen for storing) . The matrix header size is constant, however the size of the matrix itself may vary from image to image and usually is larger by orders of magnitude.
To tackle this issue OpenCV uses a reference counting system. The idea is that each *Mat* object has its own header, however the matrix may be shared between two instance of them by having their matrix pointer point to the same address. Moreover, the copy operators **will only copy the headers**, and as also copy the pointer to the large matrix too, however not the matrix itself.
OpenCV is an image processing library. It contains a large collection of image processing functions. To solve a computational challenge, most of the time you will end up using multiple functions of the library. Because of this, passing images to functions is a common practice. We should not forget that we are talking about image processing algorithms, which tend to be quite computational heavy. The last thing we want to do is further decrease the speed of your program by making unnecessary copies of potentially *large* images.
To tackle this issue OpenCV uses a reference counting system. The idea is that each *Mat* object has its own header, however the matrix may be shared between two instance of them by having their matrix pointers point to the same address. Moreover, the copy operators **will only copy the headers** and the pointer to the large matrix, not the data itself.
..code-block:: cpp
:linenos:
@@ -37,7 +39,7 @@ To tackle this issue OpenCV uses a reference counting system. The idea is that e
C = A; // Assignment operator
All the above objects, in the end point to the same single data matrix. Their headers are different, however making any modification using either one of them will affect all the other ones too. In practice the different objects just provide different access method to the same underlying data. Nevertheless, their header parts are different. The real interesting part comes that you can create headers that refer only to a subsection of the full data. For example, to create a region of interest (*ROI*) in an image you just create a new header with the new boundaries:
All the above objects, in the end, point to the same single data matrix. Their headers are different, however, and making a modification using any of them will affect all the other ones as well. In practice the different objects just provide different access method to the same underlying data. Nevertheless, their header parts are different. The real interesting part is that you can create headers which refer to only a subsection of the full data. For example, to create a region of interest (*ROI*) in an image you just create a new header with the new boundaries:
..code-block:: cpp
:linenos:
@@ -45,7 +47,7 @@ All the above objects, in the end point to the same single data matrix. Their he
Mat D (A, Rect(10, 10, 100, 100) ); // using a rectangle
Mat E = A(Range:all(), Range(1,3)); // using row and column boundaries
Now you may ask if the matrix itself may belong to multiple *Mat* objects who will take responsibility for its cleaning when it's no longer needed. The short answer is: the last object that used it. For this a reference counting mechanism is used. Whenever somebody copies a header of a *Mat* object a counter is increased for the matrix. Whenever a header is cleaned this counter is decreased. When the counter reaches zero the matrix too is freed. Because, sometimes you will still want to copy the matrix itself too, there exists the :basicstructures:`clone() <mat-clone>`or the:basicstructures:`copyTo() <mat-copyto>` function.
Now you may ask if the matrix itself may belong to multiple *Mat* objects who takes responsibility for cleaning it up when it's no longer needed. The short answer is: the last object that used it. This is handled by using a reference counting mechanism. Whenever somebody copies a header of a *Mat* object, a counter is increased for the matrix. Whenever a header is cleaned this counter is decreased. When the counter reaches zero the matrix too is freed. Sometimes you will want to copy the matrix itself too, so OpenCV provides the :basicstructures:`clone() <mat-clone>`and:basicstructures:`copyTo() <mat-copyto>` functions.
..code-block:: cpp
:linenos:
@@ -59,34 +61,34 @@ Now modifying *F* or *G* will not affect the matrix pointed by the *Mat* header.
..container:: enumeratevisibleitemswithsquare
* Output image allocation for OpenCV functions is automatic (unless specified otherwise).
*No need to think about memory freeing with OpenCVs C++ interface.
* The assignment operator and the copy constructor (*ctor*)copies only the header.
*Use the :basicstructures:`clone()<mat-clone>`or the:basicstructures:`copyTo() <mat-copyto>` function to copy the underlying matrix of an image.
*You do not need to think about memory management with OpenCVs C++ interface.
* The assignment operator and the copy constructor only copies the header.
*The underlying matrix of an image may be copied using the :basicstructures:`clone()<mat-clone>`and:basicstructures:`copyTo() <mat-copyto>` functions.
*Storing* methods
=================
This is about how you store the pixel values. You can select the color space and the data type used. The color space refers to how we combine color components in order to code a given color. The simplest one is the gray scale. Here the colors at our disposal are black and white. The combination of these allows us to create many shades of gray.
This is about how you store the pixel values. You can select the color space and the data type used. The color space refers to how we combine color components in order to code a given color. The simplest one is the gray scale where the colors at our disposal are black and white. The combination of these allows us to create many shades of gray.
For *colorful* ways we have a lot more of methods to choose from. However, every one of them breaks it down to three or four basic components and the combination of this will give all others. The most popular one of this is RGB, mainly because this is also how our eye builds up colors in our eyes. Its base colors are red, green and blue. To code the transparency of a color sometimes a fourth element: alpha (A) is added.
For *colorful* ways we have a lot more methods to choose from. Each of them breaks it down to three or four basic components and we can use the combination of these to create the others. The most popular one is RGB, mainly because this is also how our eye builds up colors. Its base colors are red, green and blue. To code the transparency of a color sometimes a fourth element: alpha (A) is added.
However, they are many color systems each with their own advantages:
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.
* 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. Using you may for example dismiss the last component, making your algorithm less sensible to light conditions of the input image.
* 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 last component, making your algorithm less sensible 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.
Now each of the building components has their own valid domains. This leads to the data type used. How we store a component defines just how fine 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 case of three components this already gives 16 million possible colors to represent (like in case of RGB) 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 building components has their own valid domains. This leads 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 case of three components this already gives 16 million possible colors to represent (like in case of RGB) 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 explicitly a *Mat* object
Creating a *Mat* object explicitly
==================================
In the :ref:`Load_Save_Image` tutorial you could already see how to write a matrix to an image file by using the :readWriteImageVideo:` imwrite() <imwrite>` function. However, for debugging purposes it's much more convenient to see the actual values. You can achieve this via the << operator of *Mat*. However, be aware that this only works for two dimensional matrices.
In the :ref:`Load_Save_Image` tutorial you have already learned how to write a matrix to an image file by using the :readWriteImageVideo:` imwrite() <imwrite>` function. However, for debugging purposes it's much more convenient to see the actual values. You can do this using the << operator of *Mat*. Be aware that this only works for two dimensional matrices.
Although *Mat*is a great class as image container it is also a general matrix class. Therefore, it is possible to create and manipulate multidimensional matrices. You can create a Mat object in multiple ways:
Although *Mat*works really well as an image container, it is also a general matrix class. Therefore, it is possible to create and manipulate multidimensional matrices. You can create a Mat object in multiple ways:
..container:: enumeratevisibleitemswithsquare
@@ -103,13 +105,13 @@ Although *Mat* is a great class as image container it is also a general matrix c
For two dimensional and multichannel images we first define their size: row and column count wise.
Then we need to specify the data type to use for storing the elements and the number of channels per matrix point. To do this we have multiple definitions made according to the following convention:
Then we need to specify the data type to use for storing the elements and the number of channels per matrix point. To do this we have multiple definitions constructed according to the following convention:
For instance, *CV_8UC3* means we use unsigned char types that are 8 bit long and each pixel has three items of this to form the three channels. This are predefined for up to four channel numbers. The :basicstructures:`Scalar <scalar>` is four element short vector. Specify this and you can initialize all matrix points with a custom value. However if you need more you can create the type with the upper macro and putting the channel number in parenthesis as you can see below.
For instance, *CV_8UC3* means we use unsigned char types that are 8 bit long and each pixel has three of these to form the three channels. This are predefined for up to four channel numbers. The :basicstructures:`Scalar <scalar>` is four element short vector. Specify this and you can initialize all matrix points with a custom value. If you need more you can create the type with the upper macro, setting the channel number in parenthesis as you can see below.
+ Use C\\C++ arrays and initialize via constructor
@@ -118,7 +120,7 @@ Although *Mat* is a great class as image container it is also a general matrix c
:tab-width:4
:lines:35-36
The upper example shows how to create a matrix with more than two dimensions. Specify its dimension, then pass a pointer containing the size for each dimension and the rest remains the same.
The upper example shows how to create a matrix with more than two dimensions. Specify its dimension, then pass a pointer containing the size for each dimension and the rest remains the same.
+ Create a header for an already existing IplImage pointer:
@@ -176,7 +178,7 @@ Although *Mat* is a great class as image container it is also a general matrix c
..note::
You can fill out a matrix with random values using the :operationsOnArrays:`randu() <randu>` function. You need to give the lower and upper value between what you want the random values:
You can fill out a matrix with random values using the :operationsOnArrays:`randu() <randu>` function. You need to give the lower and upper value for the random values:
@@ -184,10 +186,10 @@ Although *Mat* is a great class as image container it is also a general matrix c
:lines:57-58
Print out formatting
====================
Output formatting
=================
In the above examples you could see the default formatting option. Nevertheless, OpenCV allows you to format your matrix output format to fit the rules of:
In the above examples you could see the default formatting option. OpenCV, however, allows you to format your matrix output:
..container:: enumeratevisibleitemswithsquare
@@ -246,10 +248,10 @@ In the above examples you could see the default formatting option. Nevertheless,
:alt:Default Output
:align:center
Print for other common items
Output of other common items
============================
OpenCV offers support for print of other common OpenCV data structures too via the << operator like:
OpenCV offers support for output of other common OpenCV data structures too via the << operator:
..container:: enumeratevisibleitemswithsquare
@@ -298,9 +300,9 @@ OpenCV offers support for print of other common OpenCV data structures too via t
:alt:Default Output
:align:center
Most of the samples here have been included into a small console application. You can download it from :download:`here <../../../../samples/cpp/tutorial_code/core/mat_the_basic_image_container/mat_the_basic_image_container.cpp>` or in the core section of the cpp samples.
Most of the samples here have been included in a small console application. You can download it from :download:`here <../../../../samples/cpp/tutorial_code/core/mat_the_basic_image_container/mat_the_basic_image_container.cpp>` or in the core section of the cpp samples.
A quick video demonstration of this you can find on `YouTube <https://www.youtube.com/watch?v=1tibU7vGWpk>`_.
You can also find a quick video demonstration of this on `YouTube <https://www.youtube.com/watch?v=1tibU7vGWpk>`_.
Unfortunetly we have no tutorials into this section. Nevertheless, our tutorial writting team is working on it. If you have a tutorial suggestion or you have writen yourself a tutorial (or coded a sample code) that you would like to see here please contact us via our :opencv_group:`user group <>`.
Unfortunetly we have no tutorials into this section. And you can help us with that, since OpenCV is a community effort. If you have a tutorial suggestion or you have written a tutorial yourself (or coded a sample code) that you would like to see here, please contact follow these instructions: :ref:`howToWriteTutorial` and :how_to_contribute:`How to contribute <>`.
This tutorial code's is shown lines below. You can also download it from `here <http://code.opencv.org/projects/opencv/repository/revisions/master/raw/samples/cpp/tutorial_code/TrackingMotion/cornerDetector_Demo.cpp>`_
@@ -62,7 +62,7 @@ The GPU has its own memory. When you read data from the hard drive with OpenCV i
I1=gI1;// Download, gI1.download(I1) will work too
Once you have your data up in the GPU memory you may call GPU enabled functions of OpenCV. Most of the functions keep the same name just as on the CPU, with the difference that they only accept *GpuMat* inputs. A full list of these you will find in the documentation: `online here <http://opencv.itseez.com/modules/gpu/doc/gpu.html>`_ or the OpenCV reference manual that comes with the source code.
Once you have your data up in the GPU memory you may call GPU enabled functions of OpenCV. Most of the functions keep the same name just as on the CPU, with the difference that they only accept *GpuMat* inputs. A full list of these you will find in the documentation: `online here <http://docs.opencv.org/modules/gpu/doc/gpu.html>`_ or the OpenCV reference manual that comes with the source code.
Another thing to keep in mind is that not for all channel numbers you can make efficient algorithms on the GPU. Generally, I found that the input images for the GPU images need to be either one or four channel ones and one of the char or float type for the item sizes. No double support on the GPU, sorry. Passing other types of objects for some functions will result in an exception thrown, and an error message on the error output. The documentation details in most of the places the types accepted for the inputs. If you have three channel images as an input you can do two things: either adds a new channel (and use char elements) or split up the image and call the function for each image. The first one isn't really recommended as you waste memory.
Alguns arquivos não foram exibidos porque demasiados arquivos foram alterados neste diff
Mostrar Mais
Referência em uma Nova Issue
Bloquear um usuário
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.