brisk hardware acceleration

[hdino]

Hi,

I tried to use brisk for the visual pipeline, but it is very slow. Can it be possible that it does a fallback to surf_cpu and is there a way to check that? I hope it does not require CUDA...

Thanks, Dino

PS: My configuration:

  frameBuilder0 {
    type brisk
    brisk
    {
        octaves 2
        uniformityRadius 25
        absoluteThreshold 100000
        maxNoKeypoints 400
        rotationInvariant true
        scaleInvariant true
        ;cameraModel RadialTangentialPinhole
        intrinsics /janETH_GS/intrinsics0
    }
  }

[furgalep]

Nothing requires cuda. Can you put in a print statement somewhere that says what pipeline it is using?

Can you double check that everything is compiled in release mode?

[simonlynen]

Which part of it is slow? Which parameters are you using? How long does it take per frame?

[hdino]

I recompiled the whole workspace in release mode (catkin_make -DCMAKE_BUILD_TYPE=Release --force-cmake) and now it is much faster.

Processing 450 images ('camera aware detection and extraction') takes ca. 18s now, not 90s as before. The scale value is still set to 1, I'm going to try 0.5 next.

[simonlynen]

@hdino Can you create some gprof pdfs for me and send them over so I can have a look where the time is spend in brisk? https://github.com/ethz-asl/programming_guidelines/wiki/Profiling-Code

[hdino]

@simonlynen Following the instructions from the wiki, i.e. typing

CPUPROFILE=/tmp/my_executable.prof LD_PRELOAD=/usr/lib/libprofiler.so.0 ./estimator.py

creates an empty my_executable.prof file. Do I have to perform other steps? Does the google profiler work with Boost Python?

I profiled the code using perf. You can find the report here: http://hllmnn.de/aslam/perfreport.log As a graph:

[furgalep]

Hi Dino, It looks like something is using a very expensive resizer (Lanczos4), can you switch this to linear for image resizing?

[hdino]

That helped a lot, the resizing is now at 0.01%: http://hllmnn.de/aslam/perfreport2.log

[simonlynen]

@hdino It looks like you are allocating a new brisk extractor at every frame. Can you make sure that you always reuse the same extractor + detector. There is a lot of memory allocation, lookup table generation etc happening on construction of BRISK, so you should avoid recreating the objects during runtime.

[hdino]

@simonlynen I'm using BRISK via a single NCameraPipeline object, calling its addImage(...) function from a loop. Thus, from my point of view the repeated allocation has to happen somewhere in that code.

[simonlynen]

@hdino Which NCameraPipeline is that? aslam_cv2? Can you point me to the header?

[hdino]

@simonlynen It's from alsam_cv: https://github.com/ethz-asl/aslam_cv/blob/master/aslam_camera_system/include/aslam/NCameraPipeline.hpp

[simonlynen]

ok, this seems ok: https://github.com/ethz-asl/aslam_cv/blob/aee649b5eeea0a06f924a642291238e22c5ed189/aslam_features2d/src/BriskFrameBuilder.cpp#L189

Interesting...