Currently, FFMPEG source files are included in highgui project file regardless of CMake WITH_FFMPEG option.
After applying this PR FFMPEG files are included only if WITH_FFMPEG option is enabled.
In C99 'inline' is not a hint to the compiler to inline the function,
it is an attribute that affects the linkage of the function. 'inline'
functions are required to have a definition in a different compiliation
unit, so compilers are free to delete 'inline' functions if they want to.
This issue can be seen in Clang when compiling at -O0. Clang
will sometimes delete 'inline' functions which creates an invalid
program.
Issue 3746: http://code.opencv.org/issues/3746
Support for the custom sink is extended to non-WinRT not for compatibility as Windows Vista client is a minimum regardless, but because it offers more flexibility, could be faster and is able to be used as an optionally different code path during sink creation based on a future configuration parameter.
My discussion and proposal to finish this change:
Devices are so easily enumerated through WinRT Windows.Devices namespace that wrapping the calls in a library is quite a chore for little benefit though to get the various modes and formats could still be a worthwhile project. For now conditional compilation to remove videodevices and any offending non-video file related activity in videodevice. In my opinion, this is a different , far less fundamental and important change which can possibly be done as a future project and also much more easily implemented in C++/CX.
ImageGrabber has the IMFSampleGrabberSinkCallback replaced with a base class (SharedSampleGrabber) which also be is base class for ImageGrabberRT. This change is necessary as the custom sink does not require a thread to pump events which is done through MediaCapture already. IMFSampleGrabberSinkCallback is the common element between both models and that piece can be shared. Initializing the new ImageGrabberRT is as simple as passing an already initialized MediaCapture object and any video format/encoding parameters.
The concurrency event is necessary to wait for completion and is the way the underlying, IAsyncAction wrappers in the task library work as well. Native WIN32 event objects would be an option if HAVE_CONCURRENCY is not defined. I could even imagine doing it with sleep/thread yield and InterlockedCompareExchange yet I am not enthusiastic about that approach either. Since there is a specific compiler HAVE_ for concurrency, I do not like pulling it in though I think for WinRT it is safe to say we will always have it available though should probably conditionally compile with the Interlocked option as WIN32 events would require HAVE_WIN32.
It looks like C++/CX cannot be used for the IMediaExtension sink (which should not be a problem) as using COM objects requires WRL and though deriving from IMediaExtension can be done, there is little purpose without COM. Objects from C++/CX can be swapped to interact with objects from native C++ as Inspectable* can reinterpret_cast to the ref object IInspectable^ and vice-versa. A solution to the COM class with C++/CX would be great so we could have dual support. Also without #define for every WRL object in use, the code will get quite muddy given that the */^ would need to be ifdef'd everywhere.
Update cap_msmf.cpp
Fixed bugs and completed the change. I believe the new classes need to be moved to a header file as the file has become to large and more classes need to be added for handling all the asynchronous problems (one wrapping IAsyncAction in a task and another for making a task out of IAsyncAction). Unfortunately, blocking on the UI thread is not an option in WinRT so a synchronous architecture is considered "illegal" by Microsoft's standards even if implementable (C++/CX ppltasks library throws errors if you try it). Worse, either by design or a bug in the MF MediaCapture class with Custom Sinks causes a crash if stop/start previewing without reinitializing (spPreferredPreviewMediaType is fatally nulled). After decompiling Windows.Media.dll, I worked around this in my own projects by using an activate-able custom sink ID which strangely assigns 1 to this pointer allowing it to be reinitialized in what can only be described as a hack by Microsoft. This would add additional overhead to the project to implement especially for static libraries as it requires IDL/DLL exporting followed by manifest declaration. Better to document that it is not supported.
Furthermore, an additional class for IMFAttributes should be implemented to make clean architecture for passing around attributes as opposed to directly calling non-COM interface calls on the objects and making use of SetProperties which would also be a set up for an object that uses the RuntimeClass activation ID.
The remaining changes are not difficult and will be complete soon along with debug tracing messages.
Update and rename cap_msmf.h to cap_msmf.hpp
Successful test - samples are grabbed
Library updated and cleaned up with comments, marshaling, exceptions and linker settings
Fixed trailing whitespace
VS 2013 support and cleanup consistency plus C++/CX new object fixed
VS 2013 Update 2 library bug fix integrated
Various minor cleanup
Create agile_wrl.h
a-wi's changes integrated
Update cap_msmf.hpp
Update cap_msmf.cpp
Regression test fixes and simplifications
Fix indentation in output that made it look like changes were dependent on WinRT when they are independent libraries.
Defaults needed flipping otherwise undesired behavior. Change is tested with combinations.
Fixed and tested
Windows Phone v8.0/v8.1 SDK for Universal Windows Apps (Windows Phone v8.1 Silverlight App support not included) and fix initial cache causing problem
In CUDA 6.0 there was a bug in NPP LUT implementation (invalid results when
src == 255). In CUDA 6.5 the bug was fixed.
Replaced NPP LUT call with own implementation (ported from master branch)
to be independant from CUDA Toolkit version.
A self-assignment leads to a call of release() with refcount being 2. In the release() method, refcount is decremented and then successfully checked for being 1. As a consequence, the underlying data is released. To prevent this, we test for a self-assignment
Fixed a memory leak in cap_dshow.cpp in videoInput::setVideoSettingCamera(). The leak was caused by not releasing an IBaseFilter object created in a call to getDevice(). Tho object is now properly released.
Updated the documents to give warning to the users of `findHomography` that the function may return an empty matrix in some cases.
The user must take care of checking that.
This fixes all problems from the article "Checking OpenCV with PVS-Studio"
<http://www.viva64.com/en/b/0191/> that are not already fixed and are
not in 3rdparty or the legacy module.
The problems fixed are two instances of useless code and one instance
of unspecified behavior (right-shifting a negative number).
Consistent with the test made in cv::boxFilter, it adjusts the kernel size to the source size only if the border is not BORDER_CONSTANT and if BORDER_ISOLATED is set. Otherwise, the source has to be considered possibly in a larger image (i.e. the source being a ROI) in witch the kernel should apply.
CvCapture_GStreamer::retrieveFrame assumes that RGB videos are 24BPP.
This is not necesarily the case, unless we explicitly tell GStreamer
that we want 24BPP RGB streams.
Adding bpp=(int)24 to the appsink caps.
Implement missing features in CvCaptureCAM_VFW class.
Implemented missing CvCaptureCAM_VFW::setProperty() member function (handling CV_CAP_PROP_FRAME_WIDTH, CV_CAP_PROP_FRAME_HEIGHT, CV_CAP_PROP_FPS properties).
Extended CvCaptureCAM_VFW::setProperty()/getProperty() functions to handle also CV_CAP_PROP_FPS property.
Minor refactoring of CvCaptureCAM_VFW class.
Fixed constant value for focus mode FOCUS_MODE_CONTINUES_PHOTO;
Add setters and getters for exposure lock and white balance lock flags;
Excluded camera restart for all setters except frame size.
Use correct integer types for arguments to TIFFGetField to avoid corruption
of values and failed loads of TIFF file when using cv::imread().
Added test where both big and little endian TIFF files are read using imread().
Fixed build of 3rdparty libtiff on big endian hosts.
Reduced memory required during decode_tile16384x16384 test by not converting
large grayscale test image to color image during read.
The LLVM/Clang 3.3 has a bug when compile a cl kernel with
assignment of a scalar to a vector data type. This patch
could work around this bug.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
EMBED_CUDA and FORCE_EMBED_OPENCV flags added to cmake macro add_android_project;
INSTALL_CUDA_LIBRARIES option added to OpenCV.mk
opencv_dynamicuda library installation with enabled OPENCV_INSTALL_MODULES flag fixed;
CUDA initialization apportunity added to OpenCVLoader.initDebug();
Tutorial-4-CUDA sample reimplemented with static OpenCV and CUDA initialization.
Env setup for testing package implemented using /etc/profile.d;
Variable with path for all native samples added;
Path for test binaries and test data updated.
OpenCV Error: Unknown error code -6 (OpenCL function is not available: [clGetPlatformIDs]) in opencl_check_fn, file /home/ahb/software/opencv/modules/ocl/src/cl_runtime/cl_runtime.cpp, line 83
The issue results from modules/ocl/src/cl_runtime/cl_runtime.cpp checking for
"linux" instead of "__linux__" (cp. http://sourceforge.net/p/predef/wiki/OperatingSystems/)
Adjust all other occurrences of "defined(linux)" as well.
Fix compilation erros when compiling this constructor.
First argument type of "convertTo" should be instance, not a pointer of instance.
First pull request was created for master branch.
But it should be marged for 2.4.
https://github.com/Itseez/opencv/pull/2113
Also deleted miscellaneous remaining multimon cruft.
Deleted #include <winuser.h>, because <windows.h> includes it
already.
This should have a nice side effect of preventing us from
accidentally using any Windows API that's too new.
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_COVERAGE"Enable coverage collection with GCov"OFFIFCMAKE_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)))
intproNumNeg=cvRound((((double)numNeg)*((double)posCount))/numPos);// apply only a fraction of negative samples. double is required since overflow is possible
# SSE3 and further should be disabled under MingW because it generates compiler errors
if(NOTMINGW)
if(ENABLE_AVX)
add_extra_compiler_option(-mavx)
ocv_check_flag_support(CXX"-mavx"_varname)
endif()
if(ENABLE_AVX2)
ocv_check_flag_support(CXX"-mavx2"_varname)
endif()
# GCC depresses SSEx instructions when -mavx is used. Instead, it generates new AVX instructions or AVX equivalence for all SSEx instructions when needed.
where :convert_to:`convertTo <>` would effectively perform *new_image = a*image + beta*. However, we wanted to show you how to access each pixel. In any case, both methods give the same result.
where :convert_to:`convertTo <>` would effectively perform *new_image = a*image + beta*. However, we wanted to show you how to access each pixel. In any case, both methods give the same result but convertTo is more optimized and works a lot faster.
@@ -31,15 +31,15 @@ Here's a sample code of how to achieve all the stuff enumerated at the goal list
Explanation
===========
Here we talk only about XML and YAML file inputs. Your output (and its respective input) file may have only one of these extensions and the structure coming from this. They are two kinds of data structures you may serialize: *mappings* (like the STL map) and *element sequence* (like the STL vector>. The difference between these is that in a map every element has a unique name through what you may access it. For sequences you need to go through them to query a specific item.
Here we talk only about XML and YAML file inputs. Your output (and its respective input) file may have only one of these extensions and the structure coming from this. They are two kinds of data structures you may serialize: *mappings* (like the STL map) and *element sequence* (like the STL vector). The difference between these is that in a map every element has a unique name through what you may access it. For sequences you need to go through them to query a specific item.
1. **XML\\YAML File Open and Close.** Before you write any content to such file you need to open it and at the end to close it. The XML\YAML data structure in OpenCV is :xmlymlpers:`FileStorage <filestorage>`. To specify that this structure to which file binds on your hard drive you can use either its constructor or the *open()* function of this:
1. **XML/YAML File Open and Close.** Before you write any content to such file you need to open it and at the end to close it. The XML/YAML data structure in OpenCV is :xmlymlpers:`FileStorage <filestorage>`. To specify that this structure to which file binds on your hard drive you can use either its constructor or the *open()* function of this:
..code-block:: cpp
string filename = "I.xml";
FileStorage fs(filename, FileStorage::WRITE);
\\...
//...
fs.open(filename, FileStorage::READ);
Either one of this you use the second argument is a constant specifying the type of operations you'll be able to on them: WRITE, READ or APPEND. The extension specified in the file name also determinates the output format that will be used. The output may be even compressed if you specify an extension such as *.xml.gz*.
@@ -64,7 +64,7 @@ Here we talk only about XML and YAML file inputs. Your output (and its respectiv
fs["iterationNr"] >> itNr;
itNr = (int) fs["iterationNr"];
#. **Input\\Output of OpenCV Data structures.** Well these behave exactly just as the basic C++ types:
#. **Input/Output of OpenCV Data structures.** Well these behave exactly just as the basic C++ types:
..code-block:: cpp
@@ -77,7 +77,7 @@ Here we talk only about XML and YAML file inputs. Your output (and its respectiv
fs["R"] >> R; // Read cv::Mat
fs["T"] >> T;
#. **Input\\Output of vectors (arrays) and associative maps.** As I mentioned beforehand we can output maps and sequences (array, vector) too. Again we first print the name of the variable and then we have to specify if our output is either a sequence or map.
#. **Input/Output of vectors (arrays) and associative maps.** As I mentioned beforehand, we can output maps and sequences (array, vector) too. Again we first print the name of the variable and then we have to specify if our output is either a sequence or map.
For sequence before the first element print the "[" character and after the last one the "]" character:
@@ -18,7 +18,7 @@ We'll seek answers for the following questions:
Our test case
=============
Let us consider a simple color reduction method. Using the unsigned char C and C++ type for matrix item storing a channel of pixel may have up to 256 different values. For a three channel image this can allow the formation of way too many colors (16 million to be exact). Working with so many color shades may give a heavy blow to our algorithm performance. However, sometimes it is enough to work with a lot less of them to get the same final result.
Let us consider a simple color reduction method. By using the unsigned char C and C++ type for matrix item storing, a channel of pixel may have up to 256 different values. For a three channel image this can allow the formation of way too many colors (16 million to be exact). Working with so many color shades may give a heavy blow to our algorithm performance. However, sometimes it is enough to work with a lot less of them to get the same final result.
In this cases it's common that we make a *color space reduction*. This means that we divide the color space current value with a new input value to end up with fewer colors. For instance every value between zero and nine takes the new value zero, every value between ten and nineteen the value ten and so on.
At first we make sure that the input images data is in unsigned char format. For this we use the :utilitysystemfunctions:`CV_Assert <cv-assert>` function that throws an error when the expression inside it is false.
@@ -70,14 +70,14 @@ We create an output image with the same size and the same type as our input. As
..code-block:: cpp
Result.create(myImage.size(),myImage.type());
Result.create(myImage.size(),myImage.type());
const int nChannels = myImage.channels();
We'll use the plain C [] operator to access pixels. Because we need to access multiple rows at the same time we'll acquire the pointers for each of them (a previous, a current and a next line). We need another pointer to where we're going to save the calculation. Then simply access the right items with the [] operator. For moving the output pointer ahead we simply increase this (with one byte) after each operation:
On the borders of the image the upper notation results inexistent pixel locations (like minus one - minus one). In these points our formula is undefined. A simple solution is to not apply the mask in these points and, for example, set the pixels on the borders to zeros:
On the borders of the image the upper notation results inexistent pixel locations (like minus one - minus one). In these points our formula is undefined. A simple solution is to not apply the kernel in these points and, for example, set the pixels on the borders to zeros:
..code-block:: cpp
Result.row(0).setTo(Scalar(0)); // The top row
Result.row(Result.rows-1).setTo(Scalar(0)); // The bottom row
Result.col(0).setTo(Scalar(0)); // The left column
Result.col(Result.cols-1).setTo(Scalar(0)); // The right column
Result.row(0).setTo(Scalar(0)); // The top row
Result.row(Result.rows - 1).setTo(Scalar(0)); // The bottom row
Result.col(0).setTo(Scalar(0)); // The left column
Result.col(Result.cols - 1).setTo(Scalar(0)); // The right column
The filter2D function
=====================
@@ -116,7 +116,7 @@ Then call the :filtering:`filter2D <filter2d>` function specifying the input, th
..code-block:: cpp
filter2D(I, K, I.depth(), kern);
filter2D(I, K, I.depth(), kern);
The function even has a fifth optional argument to specify the center of the kernel, and a sixth one for determining what to do in the regions where the operation is undefined (borders). Using this function has the advantage that it's shorter, less verbose and because there are some optimization techniques implemented it is usually faster than the *hand-coded method*. For example in my test while the second one took only 13 milliseconds the first took around 31 milliseconds. Quite some difference.
@@ -45,7 +45,7 @@ All the above objects, in the end, point to the same single data matrix. Their h
:linenos:
Mat D (A, Rect(10, 10, 100, 100) ); // using a rectangle
Mat E = A(Range:all(), Range(1,3)); // using row and column boundaries
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 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.
@@ -86,7 +86,7 @@ Each of the building components has their own valid domains. This leads to the d
Creating a *Mat* object explicitly
==================================
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.
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* 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:
@@ -113,7 +113,7 @@ Although *Mat* works really well as an image container, it is also a general mat
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
@@ -83,8 +83,8 @@ After checking that the image data was loaded correctly, we want to display our
..container:: enumeratevisibleitemswithsquare
+ *CV_WINDOW_AUTOSIZE* is the only supported one if you do not use the Qt backend. In this case the window size will take up the size of the image it shows. No resize permitted!
+ *CV_WINDOW_NORMAL* on Qt you may use this to allow window resize. The image will resize itself according to the current window size. By using the | operator you also need to specify if you would like the image to keep its aspect ratio (*CV_WINDOW_KEEPRATIO*) or not (*CV_WINDOW_FREERATIO*).
+ *WINDOW_AUTOSIZE* is the only supported one if you do not use the Qt backend. In this case the window size will take up the size of the image it shows. No resize permitted!
+ *WINDOW_NORMAL* on Qt you may use this to allow window resize. The image will resize itself according to the current window size. By using the | operator you also need to specify if you would like the image to keep its aspect ratio (*WINDOW_KEEPRATIO*) or not (*WINDOW_FREERATIO*).
We assume that by now you know how to load an image using :imread:`imread <>` and to display it in a window (using :imshow:`imshow <>`). Read the :ref:`Display_Image` tutorial otherwise.
We assume that by now you know how to load an image using :readwriteimagevideo:`imread <imread>` and to display it in a window (using :user_interface:`imshow <imshow>`). Read the :ref:`Display_Image` tutorial otherwise.
Goals
======
@@ -14,9 +14,9 @@ In this tutorial you will learn how to:
..container:: enumeratevisibleitemswithsquare
* Load an image using :imread:`imread <>`
* Transform an image from BGR to Grayscale format by using :cvt_color:`cvtColor <>`
* Save your transformed image in a file on disk (using :imwrite:`imwrite <>`)
* Load an image using :readwriteimagevideo:`imread <imread>`
* Transform an image from BGR to Grayscale format by using :miscellaneous_transformations:`cvtColor <cvtcolor>`
* Save your transformed image in a file on disk (using :readwriteimagevideo:`imwrite <imwrite>`)
Code
======
@@ -63,10 +63,7 @@ Here it is:
Explanation
============
#. We begin by:
* Creating a Mat object to store the image information
* Load an image using :imread:`imread <>`, located in the path given by *imageName*. Fort this example, assume you are loading a RGB image.
#. We begin by loading an image using :readwriteimagevideo:`imread <imread>`, located in the path given by *imageName*. For this example, assume you are loading a RGB 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:
@@ -74,15 +71,15 @@ Explanation
cvtColor( image, gray_image, CV_BGR2GRAY );
As you can see, :cvt_color:`cvtColor <>` takes as arguments:
As you can see, :miscellaneous_transformations:`cvtColor <cvtcolor>` takes as arguments:
..container:: enumeratevisibleitemswithsquare
* a source image (*image*)
* a destination image (*gray_image*), in which we will save the converted image.
* an additional parameter that indicates what kind of transformation will be performed. In this case we use **CV_BGR2GRAY** (because of :imread:`imread <>` has BGR default channel order in case of color images).
* an additional parameter that indicates what kind of transformation will be performed. In this case we use **CV_BGR2GRAY** (because of :readwriteimagevideo:`imread <imread>` has BGR default channel order in case of color images).
#. So now we have our new *gray_image* and want to save it on disk (otherwise it will get lost after the program ends). To save it, we will use a function analagous to :imread:`imread <>`: :imwrite:`imwrite <>`
#. So now we have our new *gray_image* and want to save it on disk (otherwise it will get lost after the program ends). To save it, we will use a function analagous to :readwriteimagevideo:`imread <imread>`: :readwriteimagevideo:`imwrite <imwrite>`
..code-block:: cpp
@@ -100,7 +97,7 @@ Explanation
imshow( imageName, image );
imshow( "Gray image", gray_image );
#. Add add the *waitKey(0)* function call for the program to wait forever for an user key press.
#. Add the *waitKey(0)* function call for the program to wait forever for an user key press.
..|IntelTBB|replace:: Intel |copy| Threading Building Blocks (*TBB*)
@@ -81,7 +81,7 @@ Building the OpenCV library from scratch requires a couple of tools installed be
+ An IDE of choice (preferably), or just a C\C++ compiler that will actually make the binary files. Here we will use the `Microsoft Visual Studio <https://www.microsoft.com/visualstudio/en-us>`_. However, you can use any other IDE that has a valid C\C++ compiler.
+ |CMake|_, which is a neat tool to make the project files (for your choosen IDE) from the OpenCV source files. It will also allow an easy configuration of the OpenCV build files, in order to make binary files that fits exactly to your needs.
+ |CMake|_, which is a neat tool to make the project files (for your chosen IDE) from the OpenCV source files. It will also allow an easy configuration of the OpenCV build files, in order to make binary files that fits exactly to your needs.
+ Git to acquire the OpenCV source files. A good tool for this is |TortoiseGit|_. Alternatively, you can just download an archived version of the source files from our `page on Sourceforge <http://sourceforge.net/projects/opencvlibrary/files/opencv-win/>`_
@@ -90,17 +90,25 @@ A full list, for the latest version would contain:
..code-block:: bash
opencv_core231d.lib
opencv_imgproc231d.lib
opencv_highgui231d.lib
opencv_ml231d.lib
opencv_video231d.lib
opencv_features2d231d.lib
opencv_calib3d231d.lib
opencv_objdetect231d.lib
opencv_contrib231d.lib
opencv_legacy231d.lib
opencv_flann231d.lib
opencv_calib3d249d.lib
opencv_contrib249d.lib
opencv_core249d.lib
opencv_features2d249d.lib
opencv_flann249d.lib
opencv_gpu249d.lib
opencv_highgui249d.lib
opencv_imgproc249d.lib
opencv_legacy249d.lib
opencv_ml249d.lib
opencv_nonfree249d.lib
opencv_objdetect249d.lib
opencv_ocl249d.lib
opencv_photo249d.lib
opencv_stitching249d.lib
opencv_superres249d.lib
opencv_ts249d.lib
opencv_video249d.lib
opencv_videostab249d.lib
The letter *d* at the end just indicates that these are the libraries required for the debug. Now click ok to save and do the same with a new property inside the Release rule section. Make sure to omit the *d* letters from the library names and to save the property sheets with the save icon above them.
@@ -78,6 +78,8 @@ Make sure your active solution configuration (:menuselection:`Build --> Configur
Build your solution (:menuselection:`Build --> Build Solution`, or press *F7*).
Before continuing, do not forget to add the command line argument of your input image to your project (:menuselection:`Right click on project --> Properties --> Configuration Properties --> Debugging` and then set the field ``Command Arguments`` with the location of the image).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
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.