# I’ve just custom-compiled OpenCV.

One trend in computing is AI, and a subject related to AI, is Computer Image Recognition, which could also be called ‘Computer Vision’. And there exists an Open-Source library for that, called ‘OpenCV‘. While I tend to think of it mainly as a Linux thing, it’s also possible to download and install OpenCV on Windows.

The version of OpenCV which Linux users obtain from the package manager, tends to be an outdated version, which under Debian / Stretch, is version 2.4.9 . I have a Debian / Stretch, Debian 9 computer I name ‘Plato’, and its hardware is decently strong. But one thing I just wanted to do, was to install a more up-to-date version of OpenCV on it, that being version 3.4.2 . The way to do this under Linux, is to custom-compile. And so doing that was an overnight project this morning.

One drawback to using OpenCV remains, that it does not seem to have many working applications out-of-the-box. It offers an API, and one needs to be a very good C++ programmer, to make any use of that API. But interestingly enough, there is a demonstration application these days, called “OpenCV Demonstrator“. If one has the appropriate version of OpenCV installed, one can also custom-compile the Demonstrator.

I made some observations about these two projects the hard way this morning.

OpenCV itself is very complex and feature-laden, yet, because it’s designed to be compiled using ‘CMake’, its source files can be configured to the range of libraries a user already has installed, and building it was rather straightforward for me.

But while the Demonstrator has fewer features as such, I found it to be difficult to compile. And this is the reason why:

OCVDemo::OCVDemo(::utils::CmdeLine &cmdeline, const std::string &prefixe_modele_)
{
std::string prefixe_modele = prefixe_modele_;
if(prefixe_modele.size() == 0)
prefixe_modele = "odemo";

infos("OCVDemo::OCVDemo() (constructeur).");
::utils::model::Localized::current_language = Localized::LANG_EN;
video_en_cours = false;
video_stop = false;
outil_dessin_en_cours = 0;
entree_video = false;
ignore_refresh = false;
demo_en_cours = nullptr;
etat_souris = 0;
instance = this;
lock = false;
rp = nullptr;
fs_racine = new ::utils::model::FileSchema(::utils::get_fixed_data_path()
+ PATH_SEP + prefixe_modele + "-schema.xml");
::utils::mmi::NodeViewConfiguration vconfig;

chemin_fichier_config = ::utils::get_current_user_path() + PATH_SEP + "cfg.xml";
if(!files::file_exists(chemin_fichier_config))
{
modele_global = ::utils::model::Node::create_ram_node(fs_racine->get_schema("global-schema"));
modele_global.save(chemin_fichier_config);
}
else
{
modele_global = ::utils::model::Node::create_ram_node(fs_racine->get_schema("global-schema"), chemin_fichier_config);
if(modele_global.is_nullptr())
{
modele_global = ::utils::model::Node::create_ram_node(fs_racine->get_schema("global-schema"));
modele_global.save(chemin_fichier_config);
}
}




This style of coding is quite valid, and uses nested namespaces. The namespace ‘utils’ has the namespace ‘model’ nested inside it, and unless the correct ‘using’ declarations have been given, a series of identifiers needs to be concatenated, using the charaters ‘::’. Here’s the problem:

The namespace ‘utils’ was already defined. The way much of the code was downloaded, it had no other symbols in front of it when invoked. This caused many fatal compile errors, because such a use of a symbol is ambiguous. Each use of the ‘utils’ namespace, is the namespace which the Demonstrator project defined itself. And so each and every use of it must be changed to ‘::utils’, which is the standard way to tell the compiler, to use the version of the symbol which is itself global and not nested inside another namespace.

Doing this editing can take hours, provided that the power-user recognizes what was wrong with the code. Aside from that, nothing was wrong with the code.

Dirk

This site uses Akismet to reduce spam. Learn how your comment data is processed.