kinectAR working with OpenCV 3.0+

[ana-GT]

For users of OpenCV 3.0+:

As of January 1st, kinectAR was only able to work with ALVAR 2.0, which also only works with OpenCV < 2.4. I updated both ALVAR and kinectAR to work with the latest OpenCV (3.0+). The updated versions are here:

Alvar (working with OpenCV 3.0): https://github.com/ana-GT/alvar_updated
KinectAR (working with OpenCV 3.0): https://github.com/ana-GT/kinectAR_updated

I have been using my updated ALVAR and so far it is working fine. I have NOT tested my updated kinectAR yet, but since all the changes were mostly updated headers I am nearly sure it should be fine as well.

[ndantam]

How hard would it be to support both OpenCV 2.x and OpenCV 3 in kinectAR?

-ntd

On 02/05/2015 06:51 PM, Ana wrote:

For users of OpenCV 3.0+:

As of January 1st, kinectAR was only able to work with ALVAR 2.0, which also only works with OpenCV < 2.4. I updated both ALVAR and kinectAR to work with the latest OpenCV (3.0+). The updated versions are here:

Alvar (working with OpenCV 3.0): https://github.com/ana-GT/alvar_updated
KinectAR (working with OpenCV 3.0): https://github.com/ana-GT/kinectAR_updated

I have been using my updated ALVAR and so far it is working fine. I have NOT tested my updated kinectAR yet, but since all the changes were mostly updated headers I am nearly sure it should be fine as well.

---

Reply to this email directly or view it on GitHub:
#1

Neil T. Dantam
http://www.Neil.Dantam.name

[ana-GT]

I suppose not too hard once the files are properly fixed (adding something like #ifdef OPENCV_VERSION_2 to address the different versions in the headers or wherever it could be necessary).

Note that using OpenCV 3.0 is optional (a lot of people are still using the 2.4.x versions). In our particular case, we had to switch to 3.0 because we are using the short-range PrimeSense, for which only OpenCV > 3.0 has the appropriate OpenNI2 wrappers (OpenCV 2.4.x supports OpenNI alone, which is fine for regular Kinects).

[ndantam]

I just did a diff on the kinectAR repos (why did you lose the version history on your updated repo?!), and the differences look trivial. Unless I'm missing something, this should be handled with autoconf rather than having separate repos.

[ndantam]

Also, don't hardcode paths to $HOME in the Makefile.am! Pass as arguments to configure or put a config.site file under your $prefix. Here's the config.site I used:

CPPFLAGS="-I/home/ntd/local/include"
LDFLAGS="-L/home/ntd/local/lib"
FCFLAGS="-I/home/ntd/local/include -g -O2 -pipe"
CFLAGS="-g -O2 -pipe"

Pkg-config can also help with this kind of thing.

[ana-GT]

If I remember correctly, in the updated version of kinectAR I added an additonal CMakeLists.txt (it is easier to tweak when you have some libraries installed locally)

PS.- I know it is bad practice to hard-code paths - I was in a rush when I updated the files (I did not think anybody else was going to use it other than myself)

[ndantam]

Ok, there's surely a way to make CMake reasonably handle this configuration. Maybe setting passing in CPPFLAGS=X LDFLAGS=Y when calling cmake, and passing a version number to find_package()?