resolving include conflicts

advanced
#1

i have a meta/style question that i’ve run into.

i recently added a file to one of my addons called “Tracker.h” https://github.com/kylemcdonald/ofxCv/blob/master/src/Tracker.h

i also have an addon called ofxFaceTracker that uses a file called “Tracker.h” https://github.com/kylemcdonald/ofxFaceTracker/blob/master/src/ofxFaceTracker.h

but these two “Tracker.h” files are different. one is from ofxCv, the other is from a library called FaceTracker by jason saragih.

how can i disambiguate which one i mean?

i know historically i’ve seen people use crazy filenames, so my “ofxCv/src/Tracker.h” would become “ofxCv/src/ofxCvTracker.h”. but this feels really bad to me.

i’ve also seen proper open source developers use bigger include paths, like:

  
  
#include "ofxCv/Tracker.h"

which would be presumably located at “ofxCv/include/ofxCv/Tracker.h” which feels unnecessarily deep. this also requires me to manually add the include path to the xcode search path, which isn’t a huge deal because i already have to add the opencv search path…

so what’s the right way to solve this problem in general?

ofxOpenNI Development
#2

Is it just the file names, or the class names too?

If the class names are the same (and if you might ever need to use both these classes at the same time) then either:

* You have to use the long/crazy name approach
* Or you have to use a namespace

As far as I know, no amount of file/folder trickery will get you round a “Redefinition of class Foo” compiler error other than using a namespace…

Some good things about namespaces: they can be temporarily re-assigned a different name if (in the extremely unlikely case) you should get a clash of names and namespace’s and can be plain ignored except when needed…

The good thing about crazy names: you don’t have to use namespaces.

[Maybe I’m wrong, but thinking about it -> even with a namespace you’re gonna need to either not have one file in your project (and just use a header include) or use a namespace AND a nested folder structure for at least one of them…so crazy names are not looking so crazy maybe???]

That is one ugly problem :wink:

#3

kyle actually what you said are the solutions, having a folder so the includes are:

  
  
#include ofxCv/Tracker.h

or adding the prefix to the name of the file like:

  
  
#include "ofxCvTracker.h"

we’ve been using the prefix solution and even if it’s not very orthodox i think it’s ok, it’s indeed one character shorter than the folder solution and avoids so many folder levels.

The same goes for namespaces you can explicitly create namespaces or use prefixes as in openGL or openCV 1.x

#4

thanks for the feedback arturo + matt! fortunately it’s just the filenames, as both Tracker classes are in their own namespaces.

i’ll have to think a little about which option to pick. i’m not a fan of so many folder levels, but if a file contains a class i prefer that the file has the same name as the class…

#5

Hey Kyle

Been trying out ofxCv and ofxFaceTracker (got in contact with Jason and he was super prompt and helpful)…

I ported over a 062 project of mine to 007 so I could compare openCV Haar finding with FaceTracker…

I’ve found that it IS possible to compile ofxCv and ofxFaceTracker together in CB (win) and Xcode (mac) but only if you do a ‘magic dance’ to get the two Tracker.h files to play nice.

Basically it goes:
Step to the right: add src and libs for both ofxCv and ofxFaceTracker;
Step to the left: try to compile and get: ‘FACETRACKER’ has not been declared OR ‘FACETRACKER’ is not a namespace-name (oh but it has…and oh but it is…isn’t it?)
Step to the right: Try a bunch of other things with header includes paths etc that are all irrelevant OR just don’t do any of that…
Step to the left again: …and just remove Tracker.h and Tracker.cpp from ofxCv (has to be ofCv’s Tracker) and hit compile (oh yes there goes Tracer.cc making a nice .o)
Step to the right again: drag Tracker.h/cpp back in and voila!
Step to the never: have to do the dance again once you do this the first time - even if you clean all dependencies…

At first I thought I was dreaming but just double/triple checked that dance and it’s repeatable (I checked on Xcode, but I remember was pretty much the same in C::B)…

…perhaps this should be in another thread but also found:

On Windows: In Utilities.h the enum ABSOLUTE is causing some kind of conflict (trying a “Find declaration…” with the IDE didn’t get me anywhere so it might be in a a non-header library somewhere. It needs a:

  
#ifdef ABSOLUTE  
#undef ABSOLUTE  
#endif

in the Utilities.h or a rename in the enum.

Once I threaded FaceTracker I was getting assert crashes every 1 to 60 seconds:

  
“OpenCV Error: Assertion failed (0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows) in Mat, file c:/OpenCV-2.2.0/modules/core/src/matrix.cpp, line 307”

After laborious printf debugging I found that inserting:

  
    if (temp_.rows > 0) R.width = (((R.width) < (temp_.rows)) ? (R.width) : (temp_.rows));  
    if (temp_.cols > 0) R.height = (((R.height) < (temp_.cols)) ? (R.height) : (temp_.cols));

before

  
temp_ = small_(R).clone();

at line 180 of Tracker.cc fixes the problem - R is a rect that occassionally returns a width and/or height smaller than temp_.cols and/or temp_.rows…

Jason says:

Yeah, there’s a bug in my code to do with re-initialising the face when it is close to the periphery of the image. I was planning to fix that, but keep putting it off. Anyways, if your fix stops the crashes and the tracker continues to “work” I guess that’s sufficient for now.

#6

wow, that’s the first bug i’ve seen in FaceTracker. super glad you shared that. i’m working on some longer term installations now and that would have been deadly.

i’m confused about ABSOLUTE. it shouldn’t be inside Utilities.h anywhere. there is only RunningBackground::ABSOLUTE. what’s going on there?

i’ve also seen that ‘dance’ once, to get things working. i have a feeling that if you configured the xcode project to compile things in a certain order, it would work. but ultimately, that’s not a cross-IDE solution. i’m leaning more towards using a subdirectory right now. if i go the ofxCv-prefix route there’s a chance of conflicting with ofxOpenCv…

#7

oh yes! my bad…looking at the #include not the class name (doh)

RunningBackground.h has the ABSOLUTE conflict.

i’m leaning more towards using a subdirectory right now.

So the include would be <ofxCv/ofxCv.h>? Will that stop the two Tracker classes/files conflicting?

if i go the ofxCv-prefix route there’s a chance of conflicting with ofxOpenCV

How so? Auto-complete in the IDE or…?

[Hijacking again] Comparing openCV Haar vs FaceTrack I’ve found two things:

* the standard frontal cascade with Haar finding is more resilient to non-frontal faces (ie., heads turned to the side, or in my case camera’s installed to one side) -> this makes sense and Jason has offered to help retrain, though I’m chasing a deadline on the project…

* performance wise they seem to be about the same if not better for FaceTracker if it is *already* tracking a face, but when no face is being tracked there seems to be a large performance hit (threaded or non-threaded: image capture slows right down)…do you know what causes that?

#8

yes, the include could actually be ofxCv.h and inside ofxCv it would use the relative pathnames.

the conflict with ofxOpenCv would be if i wanted ofxCv to have ofxCvHaarFinder and someone was also using ofxOpenCv in their project. this is admittedly rare.

haar vs facetracker: yes, all your observations are correct. facetracker is optimized for faces that are already being tracked. there are some parameters inside ofxFaceTracker that allow you to trade accuracy for lag:

  
  
void ofxFaceTracker::setup() {  
	wSize1.resize(1);  
	wSize1[0] = 7;  
	  
	wSize2.resize(3);  
	wSize2[0] = 11;  
	wSize2[1] = 9;  
	wSize2[2] = 7;

these describe the scaling factors for the search window size. changing these might help. i haven’t spent a lot of time poking around with them, so please share anything you discover.

#9

btw, kyle, i had a hard time yesterday fixing dependencies because you include the whole ofxCv and cv namespaces in the .h :slight_smile:

in windows there’s a Ptr type declared somewhere in quicktime so including the whole cv it’s super problematic. namespaces shouldn’t be included in the headers but in the .cpp

i finally solved it by moving the quicktime includes to the cpp in the videograbber and videoplayer but would be good to fix this. i’ll take a look when i have some time.

#10

hmm, i guess the correct solution then is to move using namespace to the testApp.cpp for the example apps. i’ll make that change soon. sorry arturo.

#11

i fixed the include problem, i went for the directory approach:

https://github.com/kylemcdonald/ofxCv/tree/master/libs/ofxCv/include/ofxCv
https://github.com/kylemcdonald/ofxCv/tree/master/libs/ofxCv/src

the directory structure is kind of deep now, but it feels much cleaner. i could shorten it to just libs/ofxCv, but i thought it would be better to be consistent with other libraries.

i also fixed the namespace bug, arturo. no more using namespace in ofxCv.h

i’ll update the ofxFaceTracker examples now to reflect these changes.

#12

:slight_smile: thanks!

and yes better to have it in src to be consistent. linux makefiles use the file system structure to guess where things are. It would have worked with libs/ofxCv, but if we make other tools in the future to automate things like project creation, having a predictable fs structure will help

#13

on an aside, all the meshes returned by ofxFaceTracker are now index-based instead of multiple vertices. it’s internally much cleaner, i’m happier with it. if you need to convert back to the old style, i have an example that includes some helper methods, ‘ofMeshUtils’

https://github.com/kylemcdonald/ofxFaceTracker/blob/master/example-calibrated/src/ofMeshUtils.cpp

personally, i think it would be awesome for a small collection of mesh helpers like this to be in the core… :slight_smile:

#14

that’s great, i was trying to deform the mesh manually some days ago and realized that some vertices where duplicated cause the mesh wasn’t indexed

#15

so i’m having problems with this again.

the issue (i should have realized) is that even when ofxCv uses include paths properly, that doesn’t mean other libraries will.

so i’ve heard from people who are having trouble with ofxFaceTracker because when FaceTracker tries to include Tracker.h it uses the ofxCv/Tracker.h rather than the the FaceTracker/Tracker.h

is there any way to get around this? i’m starting to think that the prefix approach (ofxCvTracker.h) is better. but then i’ll get a conflict when ContourFinder.h becomes ofxCvContourFinder.h. argghh. does anyone have more suggestions?

#16

i think the prefix is the safest, if you are concerned with ofxCv/ofxOpenCv clashing, add the opencv libraries to ofxCv. i guess most people using ofxCv are not using ofxOpenCv anymore anyway.

I would go with this system also in case we add namespaces to OF

#17

At my day job, we arrange our code libraries so that the header files are at the top level inside the library directory. This makes it possible to write #include “libraryname/headerfile.h”.

For this to work with Openframeworks, the file structure on disk would have to be changed so that the contents of “include” directories are moved up one level everywhere, which I guess would be impractical (and maybe not desirable).

For example, if libs/glu/include/glu.h was moved to libs/glu/, you would be able to write #include “glu/glu.h” To include the header file.

As it stands now, you could of course write #include “glu/inlcude/glu.h”, but I guess that is not desirable? Or in the case of an addon #include “ofxOpenCV/src/ofxOpenCv.h”.

#18

Hi,

I am trying to use your library with a openFrameworks project on windows VS2008. Its the basic example provided in ofxfacetracker. With some tweaks its compiled but

I have the following runtime failure, which I am not able to solve.

–> In following function I am getting assertion failure

  
void Tracker::Load(const char* fname)  
{  
	ifstream s(fname); assert(s.is_open()); this->Read(s); s.close(); return;  
}

for some reason the code is not able to read the “face2.tracker” file.

Will it make any difference on linux/ windows? Am I making any particular mistake here?

Cheers,
Paras.

#19

make sure you add the model/ directory to the data/ directory, otherwise you’ll get an error because it’s trying to load the face model but can’t find the data.

#20

Thanks for the reply,
I had the model in data folder. I solved the problem by adding bin to VC o/p directorics.