You can record with the SDK's camera sample without trouble, and the recorded file plays in the bundled viewer, but the moment CMake configures the playback and export samples it stops with an OpenCV error. Nothing is missing from the download. The recording sample never asks for OpenCV, while the playback and export samples compile against it, and their configure still resolves to the prebuilt OpenCV in the SDK's dependencies folder — a build made for a toolchain older than yours. The sections below run in the order you will meet them: what CMake is telling you, why the bundled build is the blocker, why installing OpenCV alone does not clear it, and the one cache entry that finishes the job. A few minutes of CMake GUI work; no SDK reinstall.
Why do only the playback and export samples fail to configure?
The recording sample links only against the SDK's own libraries, while the playback and export samples also compile their overlay drawing and image export against OpenCV, so their CMakeLists.txt runs find_package(OpenCV REQUIRED) and CMake stops at configure time when no package configuration file turns up.
Configure and build are different stages. CMake first resolves every dependency and writes the project files; nothing compiles until Configure and Generate both succeed. That is why the error text mentions a package configuration file instead of a compiler: in config mode the OpenCV search looks for OpenCVConfig.cmake, and the message says CMake did not find a package configuration file provided by OpenCV.
The contrast between the two tutorials is the clue. Playback draws overlays and export writes image files, and both jobs go through OpenCV, so the samples that fail are exactly the samples that need it. Leave compiler settings alone; the failure happens before any compilation starts.
Why can't CMake use the OpenCV bundled with the SDK?
The copy inside the SDK's dependencies folder is a prebuilt OpenCV compiled for one toolchain generation — VS2015 — while your project builds with a newer one, VS2017, so that package cannot serve the samples' build; the reliable move is an OpenCV made with your own toolchain.
A prebuilt C++ library is not portable across compiler generations. The dependencies folder carries a binary OpenCV as the SDK's default convenience copy, and a package built for another generation either fails the configure or leaves link and run-time errors behind.
The bundled copy also tends to carry one configuration and one set of binaries, tuned to the SDK's own examples. The rule that decides everything after this point: the samples must consume an OpenCV build produced by the same toolchain generation, the same architecture and the same build configuration you compile with. Your first Configure recorded exactly that bundled path, which is why the next section exists.
Why does it still fail after you install OpenCV and add it to PATH?
The PATH environment variable only changes where the program looks for DLLs at run time; the samples' configure keeps reading a cache entry that recorded the bundled OpenCV path on your first run, so the same failure returns until you overwrite that entry.
Two different lookups are in play. PATH governs DLL loading after the build exists; package resolution at configure time is governed by the cache, and the SDK's sample scripts keep their own entry for it: OPENCV_CONFIG_PATH. On the first Configure, that entry recorded the bundled location — the SDK's install folder under dependencies, in a subfolder named opencv3.1.0.
CMake trusts stored cache values on every later run. Installing OpenCV 4.0.1 elsewhere and adding its bin folder to the environment changes neither the cache entry nor the scripts that read it, so Configure fails again with identical text. The cure is one edit to that entry, not an environment change.
Which folder does the OpenCV config path need to point to?
Point it at the directory that contains OpenCVConfig.cmake from the OpenCV build you made or installed with your toolchain — never the source checkout and never the SDK's dependencies folder; for an installed OpenCV 4.0.1 that directory sits inside your OpenCV install tree, and a file search finds it.
OpenCVConfig.cmake is the file the OpenCV search reads in config mode. It computes the include directories and the library files for the OpenCV build it belongs to, so the folder you name decides which OpenCV the samples compile against.
Use the copy produced by your build or your installer. The copy in a source checkout belongs to building OpenCV itself, and the copy under the SDK's dependencies folder is the one you are replacing. After an install, search the OpenCV install directory for OpenCVConfig.cmake and take the folder that holds it: the value is the folder, not the file.
How do you set the cache entry and reconfigure?
Open cmake-gui on the samples folder, press Configure once so the OpenCV entries appear, set OPENCV_CONFIG_PATH — listed just below OPENCV_FOUND — to your OpenCV install's config directory, press Configure again until no red entries remain, then Generate and build in your IDE.
- Start clean: delete the samples' build folder, or clear the cache in the GUI, so no bundled path survives from earlier attempts.
- Point the source at the samples folder — the one whose CMakeLists.txt adds the playback and export samples — set a fresh build folder, and press Configure.
- Find OPENCV_CONFIG_PATH in the entry list, just below OPENCV_FOUND; it still holds the bundled value described above.
- Replace it with your OpenCV folder, the directory containing OpenCVConfig.cmake.
- Press Configure again and confirm the entry kept your value and no variable shows in red.
- Press Generate, open the generated solution, and build the playback and export targets first.
What has to match between the OpenCV build and your project?
Four things: toolchain generation, architecture, build configuration and a package file. Use an OpenCV built with the same toolchain generation as the samples, for the same architecture, with Debug and Release variants if you build both, and with an OpenCVConfig.cmake CMake can read.
| Requirement | What to check | What a mismatch looks like |
|---|---|---|
| Toolchain generation | OpenCV built with the same compiler generation as the samples; the reported failure pairs a VS2015 build with a VS2017 project | Configure rejects the package, or the link stage stops on unresolved symbols |
| Architecture | 64-bit OpenCV for 64-bit samples | Link errors about incompatible machine types |
| Build configuration | Debug samples take Debug OpenCV libraries, Release takes Release | Two conflicting C runtimes load, and the process can crash at start-up |
| Package file | The folder you set contains OpenCVConfig.cmake | The configure output reports no package configuration file provided by OpenCV |
Version is the softer constraint. Check the find_package line in the sample's CMakeLists.txt: when it names an exact version, satisfy it; when it pins none, a newer major build can serve, and a setup can move from a bundled 3.1.0 to an installed 4.0.1 with no source changes. Keep one OpenCV build per toolchain per machine, and note its version and folder next to the build instructions.
How do you verify the fix end to end?
Reconfigure, then check three things in order: the cache entry holds your OpenCV folder, the Configure output reports OpenCV found at the version you installed, and the playback and export targets build and run without a missing-DLL message.
Run time needs one more check. The fresh executable loads the OpenCV DLLs that PATH serves, so put the bin folder of the same OpenCV build on PATH now — this is the step where the environment variable finally does its job. If the process complains about a missing entry point or a wrong DLL version, an older OpenCV copy is shadowing the new one, and the vision software missing entry point fix walks that hunt. Playback should open any file the viewer opens, and export should write images you can open anywhere.
When is the config path not the problem?
If the samples now configure and build but fail later — at start-up, at load of a recorded file, or only on a second machine — the configure stage is solved and the remaining suspects are run-time DLLs, dependency versions or SDK-firmware alignment.
- Configure runs but headers are not found: the include side of the package is broken, and the OpenCV header diagnosis covers the causes and tests.
- Configure passes and the link fails on unresolved symbols: walk the dependency graph with the CMake dependency diagnostics for vision builds and the C++ camera SDK linking-error guide.
- The build broke after a library upgrade: the SDK build-error fix after a library upgrade matches that case.
- The same samples behave differently on a second machine or in CI: pin one version of every library, as the Docker SDK version mismatch fix shows.
- Errors appear only when the SDK talks to the camera: run a firmware and SDK alignment check next, as in the 3D camera firmware and SDK alignment guide.
Prevention is short: after any SDK update, expect the cache to offer the bundled path again and redo the single edit; keep the chosen OpenCV build pinned per machine; record the pair of versions — OpenCV and toolchain — next to the build instructions so the next engineer starts where you ended.
Can the vision controller that runs the samples build them too?
Yes — the fix is a property of the compiler and the OpenCV build, not of the machine: install the same toolchain generation and the matching OpenCV build on the controller, set the samples' config path entry to that build's OpenCVConfig.cmake folder, and reconfigure there exactly as on your bench PC.
Nothing about the procedure changes on the machine that runs the line: same toolchain generation, same matching OpenCV build, same single cache edit before Generate. A fanless vision controller keeps build and deployment on one box; the MV-VC3301H-128G66 pairs an Intel Core i3-8100 with 8 GB of RAM and a 128 GB SSD, and its 5+ LAN ports carry no PoE, so the camera keeps its own power feed.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Build order from an empty bench: pick the camera from the 3D sensors range, host the SDK on the controller above, run the samples' configure with OPENCV_CONFIG_PATH set to your OpenCV config folder, and keep one OpenCV per toolchain on every machine. A configure log you cannot decode belongs on the contact page; the rest of the build-system fixes sit on the systems topic page.
Questions
Can I fix this by copying the OpenCV DLLs next to the sample executable?
No. At configure time CMake needs OpenCVConfig.cmake to compute the include directories and import libraries, and at link time the samples consume those libraries; DLLs only matter after the build succeeds, when Windows loads them by name. Copied DLLs fix neither stage, and a wrong-version copy turns a clean build into a start-up failure.
Which OpenCV version should I install for the samples?
Read the find_package line in the sample's CMakeLists.txt first: an exact version named there must be satisfied. When no version is pinned, install a current release built with your toolchain generation; the version number is rarely the blocker. A sample set can move from a bundled 3.1.0 build to an installed 4.0.1 with no source changes once the config path points at the new build.
Where exactly is OpenCVConfig.cmake after I install OpenCV?
Search the OpenCV install directory for a file named OpenCVConfig.cmake. A build produces one copy in its build tree and another in the install tree written by the install step or the prebuilt installer; use the install-tree copy, because its paths lead to the built libraries. The copy inside the SDK's dependencies folder is the one you are replacing.
Does the same fix apply if I build the samples on Linux?
Yes, with one rule unchanged: the samples must consume an OpenCV build produced by the compiler family you build with, and the script must be shown that build. Point the equivalent path variable at the directory holding OpenCVConfig.cmake in your install prefix. The mismatch there is usually a compiler version or ABI difference rather than a toolchain generation.