Missing getFrame in your camera SDK: how to enable OpenCV support

You are halfway through wiring a camera SDK into a C++ program when the build stops on an error like 'class dai::ImgFrame' has no member named 'getFrame'. The SDK documentation shows the method, the bridge library exists on disk, and yet the compiler insists the class has no such member. This is not a broken install — it is an optional OpenCV interoperability layer that ships compiled but disabled, and your application build never switched it on. This page shows the two changes that fix it — one compile definition, one library swap — for CMake projects, plain command-line builds and IDE projects such as CodeBlocks, plus a minimal test that proves the bridge is live before you touch your inspection code.

Why does the compiler say ImgFrame has no member named getFrame?

The members exist only behind a compile definition: when the SDK headers are preprocessed without its OpenCV-support macro — DEPTHAI_OPENCV_SUPPORT in the SDK this error comes from — the getFrame and getCvFrame declarations are skipped, so the class your compiler sees genuinely lacks them.

The declarations sit inside a preprocessor conditional. Define the macro and the header declares both methods alongside the plain data accessors; omit it and those lines are dropped before compilation, so no amount of include-path fixing changes the class. Nothing in your install is broken, and the documentation is not wrong — it describes the enabled configuration.

The odd prefix in the message, using element_type = class dai::ImgFrame, is the compiler resolving your call through a smart pointer: the frame is held by pointer, and the member lookup fails on the pointed-to class. That is why the class name appears twice.

This also explains why finding libdepthai-opencv.so on disk proves nothing yet. Declarations are a compile-time question, answered per header; the bridge library is a link-time answer. Two independent gates must open, and yours stopped at the first.

Two cousin failures are worth separating now. If the SDK headers are absent from the include path altogether, the errors name files, not members — that is the camera SDK missing OpenCV headers case. And the same flag mechanism gates other features: OpenCV compiled without CUDA support shows the identical pattern with a different library.

Which two changes does the fix actually need?

Two: define the OpenCV-support compile definition in every build that includes the SDK headers, and link the bridge library — libdepthai-opencv.so — instead of the core library alone; in CMake that is one swap of targets, from depthai::core to depthai::opencv.

Neither half substitutes for the other. The definition opens the declarations; the bridge library supplies the compiled conversions those declarations promise. Skip the definition and you get the member error you have now; add the definition and forget the library, and the same code fails further down at link time with undefined references.

One confusion worth killing early: the flag is not an environment variable and carries no path. It is a valueless preprocessor definition, and it belongs in the compile command or the project's define list — not in a shell profile.

How do you enable OpenCV support in a CMake build?

Link the depthai::opencv target instead of depthai::core and the definition travels with it: the target carries both the compile definition and the bridge library as usage requirements, so a well-formed CMake project needs no manual -D flag.

The SDK exports two link targets: depthai::core, built without OpenCV internally, and depthai::opencv, the core plus the OpenCV helpers. Support switches on only through the second, which is why this line is the whole fix:

# my_app is a stand-in for your target's name
target_link_libraries(my_app PRIVATE depthai::opencv)

Keeping depthai::core reproduces the error no matter what flags you add elsewhere, because the target itself encodes the no-OpenCV variant. If CMake configured the SDK before OpenCV was on the machine, the depthai::opencv target may not exist at all — the SDK's configure log is where a cannot-find-OpenCV message shows up. The CMake OpenCV submodule find_package guide covers getting OpenCV into a CMake build, and fixing camera SDK build errors after a library upgrade covers the rebuild when versions have moved.

How do you fix it on the command line or in CodeBlocks?

Outside CMake you supply both halves by hand: the definition on every compile step, the bridge library on the link line after your objects; the two commands below carry -DDEPTHAI_OPENCV_SUPPORT at compile time and -ldepthai-opencv at link time.

g++ -std=c++14 -DDEPTHAI_OPENCV_SUPPORT -c main.cpp -o main.o
g++ main.o -o grab -ldepthai-opencv -lopencv_core -lopencv_imgproc

The -D flag belongs to the compile step; nothing about linking re-runs the preprocessor. The OpenCV libraries to list are the set pkg-config --libs opencv4 prints on your machine — the two shown are the usual minimum for frame conversion. With GNU ld, order matters: the linker resolves left to right, so -ldepthai-opencv must come after the objects that use it.

In CodeBlocks, open Project build settings and add DEPTHAI_OPENCV_SUPPORT to the preprocessor definitions; add the bridge library to the link libraries in the same dialog. An IDE hides compiler flags behind dialogs, which is why a missing define stays invisible until the build fails — and why this error turns up so often in IDE-only projects.

The one-minute diagnostic from the SDK's own maintainers: put #define DEPTHAI_OPENCV_SUPPORT as the first line of the source, before any include, rebuild, and watch the error change. It proves the diagnosis; keep the permanent definition in the build system.

What is the fastest test that proves the fix?

Build a minimal program whose only job is to call the method that failed: if it compiles, links and prints a byte count with the define active and the bridge library linked, the OpenCV path is proven before any inspection code is involved.

// probe.cpp — sdk.hpp stands in for your SDK's top-level header
#define DEPTHAI_OPENCV_SUPPORT      // diagnostic only; move it to the build system
#include <sdk.hpp>
#include <iostream>

int main() {
    std::shared_ptr<dai::ImgFrame> frame;   // null here; filled from your pipeline
    if (!frame) { std::cout << "no frame"; return 1; }
    auto data = frame->getFrame();          // the call that failed before
    std::cout << data.size();
    return 0;
}

std::shared_ptr keeps the probe realistic — your pipeline hands frames over as pointers — and auto on the return keeps it independent of the exact container type. Compile with the same flags your application uses: a clean build proves the definition, a clean link proves the library, and the printed byte count proves the path end to end. That count should equal one full frame, which is the arithmetic the section below works through.

Why does define placement and spelling decide the result?

The macro has to exist before the first SDK include is preprocessed, and it has to be spelled exactly right: a definition placed after the include arrives too late, and a misspelled one compiles silently while guarding nothing, reproducing the identical error.

A misspelled flag is the classic last mile of this fix: everything else is correct, the guard stays closed, and the build output gives no hint, because an unknown definition is not an error. Read your define list character by character when the fix seems complete but the error persists.

Three placements work, in order of preference. The build-system or project-file definition covers every translation unit at once. A per-target compile definition in CMake does the same for one target. The in-source #define DEPTHAI_OPENCV_SUPPORT before any include covers exactly one file and invites inconsistency — keep it for the probe, not for production.

What if you set the define but the linker still fails?

A linker failure means the other half is missing: undefined references to the frame-conversion symbols tell you the bridge library is not on the link line, is listed in the wrong order, or your project still links the core library alone.

Treat it as progress, not a loop: the compile gate has opened, and the link gate is next. Re-check the command-line ordering above, or swap the CMake target to depthai::opencv, which carries both halves together. If the undefined references come from your own OpenCV calls instead — cv::Mat symbols that no library satisfies — the link line is missing OpenCV itself, not the bridge; the vision SDK undefined reference guide walks that compiler-versus-library mismatch, and the camera missing from your SDK after it links covers the next failure, where the build passes but enumeration comes up empty.

Which cameras ship SDKs that follow this same pattern?

Every C++ camera SDK you will integrate follows the same shape: headers declare features, build flags open them and libraries carry them, so look for the OpenCV or frame-conversion flag in each SDK's build options before writing conversion code by hand.

Depth cameras are where the pattern bites hardest, because their frame objects carry the most metadata. The 3D sensors category holds the structured-light and ToF families; the area scan cameras and smart cameras categories cover the 2D side, where the same headers-plus-flags integration applies to GenICam-based SDKs.

For depth work, these two families cover the structured-light and ToF routes:

On the 2D side the byte arithmetic becomes concrete. The LS-CMR-0166 delivers 4000 × 3000 frames at 30 fps over USB3:

An 8-bit monochrome frame at that size is 12,000,000 bytes, which is 12,000,000 ÷ 1,048,576 ≈ 11.4 MiB. When your frame-access call reports exactly that count, one complete frame is in hand and ready to wrap:

// Illustrative: pointer and geometry come from your SDK's frame object.
cv::Mat img(cv::Size(4000, 3000), CV_8UC1, data.data());

A short count points at truncation or a format conversion — a different bug from the missing member, but one the same probe surfaces in seconds.

If you are choosing the camera as well as fixing the build, the camera finder filters by interface, resolution and shutter, and the configurator's camera step pairs camera, lens and cable in one pass. Build-system questions beyond this error live on the systems topic page; the GenICam feature tree guide is the natural next read once frames arrive, and the contact page reaches the applications team for anything that outlasts both.