Member Avatar for kevinn

I'm making a project with OpenCV about tracking. But what I want is the ability to let the user import his own tracking algorithms. Is there some way that i can check in a specified folder if there are new algorithms added and how can I include them in my code? So i want to check if there are other algorithms added and 'load' them in to my code and execute them. How can I do this?

The algorithms always have the same amount of parameters.

Edited by kevinn because: n/a
  • 2 Contributors
  • 2 Replies
  • 221 Views
  • 16 Hours Discussion Span
  • Latest Post Latest Post by kevinn

Dani AI

Generated

Good question — and is pointing you in the right direction with runtime-loaded libraries. For a reliable and maintainable plugin system, design a small, stable C-style API that every tracker plugin implements. That keeps ABI problems to a minimum and makes discovery/validation straightforward.

// tracker_plugin.h  (shared header for app + plugins)
#ifdef __cplusplus
extern "C" {
#endif

typedef struct TrackerPluginAPI {
  int api_version;                 // increment on incompatible changes
  const char* name;                // human-readable
  int num_params;                  // fixed param count
  void* (*create)(const double* params);        // returns opaque instance
  void  (*destroy)(void* instance);
  int   (*process_frame)(void* instance,
                         const unsigned char* data,
                         int width, int height);
} TrackerPluginAPI;

const TrackerPluginAPI* get_tracker_plugin_api(void);

#ifdef __cplusplus
}
#endif

Practical loader workflow: 1) enumerate the plugin folder (use std::filesystem) and filter by platform extension (.so/.dll/.dylib); 2) open each library with the platform loader and resolve get_tracker_plugin_api; 3) verify api_version and num_params; 4) call create with a fixed-size double[] parameter array (since you said parameter count is constant); 5) call process_frame as needed; 6) call destroy before unloading the library. Keep the plugin API limited to POD types and opaque pointers so you don’t cross C++ STL, exceptions, or runtime boundaries.

Troubleshooting and cautions: compile plugins with compatible compiler/settings and OpenCV ABI; do not throw exceptions across the boundary; document who allocates/frees memory; ensure dependent libraries are loadable (rpath/LD_LIBRARY_PATH on Linux, PATH on Windows); never unload a library while a thread is executing inside it. Add an api_version and optional metadata string so your app can refuse incompatible plugins gracefully.

This approach keeps the runtime loader simple and lets authors write plugins in C or C++ while avoiding fragile C++ ABI issues.

Recommended Answers

All 2 Replies

Member Avatar for rxlim

In Linux, the library for dynamic loading a library into the caller's address space is called dl, use the function dlopen to load and dlsym to resolve the function you are interested in calling. In Windows the function is called LoadLibrary and is a part of Kernel32.dll (defined in Windows.h).

Linux example: see the dlopen manual
Windows example: msdn.microsoft.com

Member Avatar for kevinn

perfect, thank you!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.