pablofdezalc/akaze

Accelerated-KAZE Features

akaze's Issues

Compile nbergst / akaze on TX2

when I try to make nbergst/akaze fork on tx2 it gives

`cc: error: unrecognized command line option '-msse2'
cc: error: unrecognized command line option '-msse3'
cc: error: unrecognized command line option '-msse4'
CMake Error at AKAZE_CUDA_generated_cuda_akaze.cu.o.cmake:207 (message):
Error generating
~cuda-akaze/build/src/CMakeFiles/AKAZE_CUDA.dir/lib/./AKAZE_CUDA_generated_cuda_akaze.cu.o

src/CMakeFiles/AKAZE_CUDA.dir/build.make:70: recipe for target 'src/CMakeFiles/AKAZE_CUDA.dir/lib/AKAZE_CUDA_generated_cuda_akaze.cu.o' failed
make[2]: *** [src/CMakeFiles/AKAZE_CUDA.dir/lib/AKAZE_CUDA_generated_cuda_akaze.cu.o] Error 1
CMakeFiles/Makefile2:168: recipe for target 'src/CMakeFiles/AKAZE_CUDA.dir/all' failed
make[1]: *** [src/CMakeFiles/AKAZE_CUDA.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
`
when I removed the lines including "-msse2 -msse3 -msse4" on ./src/CMakelist.txt, in this time when making library there is no error but in runtime I mean when I try to command

./akaze_match ../../datasets/iguazu/img1.pgm ../../datasets/iguazu/img4.pgm ../../datasets/iguazu/H1to4p

it gives the following

allocating 83.657 Mbytes of gpu memory
allocating 83.657 Mbytes of gpu memory
safeCall() Runtime API error in file <~/vision-resource/cuda-akaze/src/lib/cudaImage.cu>, line 60 : unspecified launch failure
TX2:
Cuda 9.0
gcc 5.4.0
opencv 3.4.9

Thanks for your any help ...

Current status in development

Is this repo still active? If not maybe @nbergst or @caseymcc or @bitbar could be in charge of maintainance as they are the most proactive.

Is it mandatory to convert the image to float?

Hi
I want to accelerate AKAZE on ARM processors. Before everything, the algorithm converts the 8 bit image to a float image ranging from 0 to 1. Is this mandatory? How can I avoid this?

--json command not found

Hello,
When I am running akaze_match prebuilt binaries on windows and mac, I am seeing that there is a command called --json, but when running on Amazon Linux, I am not seeing that option. I am not seeing that option in the src code. Was it renamed?

usr/bin/ld: /usr/local/lib/libAKAZE.so: undefined reference to `cudaMemcpy2DAsync

Hi ,

I am trying to compile the library on x86_64. I have the following graphics card.

$ lspci | grep VG
01:00.0 VGA compatible controller: NVIDIA Corporation GP104M [GeForce GTX 1070 Mobile] (rev a1)

I have installed cuda-toolkit 10.0 version. I can compile it successfully and generate libAKAZE_CUDA.so alibAKAZE.so. But when I try to link it with my program I am getting the follwoing error

 /usr/local/lib/libAKAZE.so: undefined reference to `cudaMemcpy2DAsync

I tried linking it with -lAKAZE -lAKAZE_CUDA options.

If I run the ldd command I am not getting any output.

$ ldd lib/libAKAZE_CUDA.so | grep cuda

but it I try compiling it on nvidia Tx2 it is able to link successfully and If I run the ldd command on tx2 I am getting output.

$ ldd lib/libAKAZE_CUDA.so | grep cuda
libcudart.so.10.0 => /usr/local/cuda-10.0/lib64/libcudart.so.10.0 (0x0000007f8ef1a000)

Please let me know if any more info is needed. Appreciate if someone please help me overcome this issue.

compile error in Visual Studio (OpenMP)

The commit e75a921 changed the type of some index variables from int to size_t, which triggers a Visual Studio compiler error (error C3016: 'i' : index variable in OpenMP 'for' statement must have signed integral type)

Illegal instruction

I am getting "Illegal instruction" when I try to run the programs after successful compilation. Have opencv 3.2.0 installed. Below is the output of cmake. Am I missing something, wrong versions?

-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- >>> Adding src subdirectory
-- Found OpenCV: /usr/local (found version "3.2.0")
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Found OpenMP: -fopenmp
OpenMP found
-- Configuring done
-- Generating done

"Error generating the nonlinear scale space!!" when call AKAZE::Create_Nonlinear_Scale_Space against a small image

When call AKAZE::Create_Nonlinear_Scale_Space against a small image (e.g. 64*64), error message says "Error generating the nonlinear scale space!! Firstly you need to call AKAZE::Allocate_Memory_Evolution()".

It happens because AKAZE check image size and does not allocate the data for the small image at https://github.com/pablofdezalc/akaze/blob/master/src/lib/AKAZE.cpp#L101. So if a small image is given, it does not allocate any data for it. I think AKAZE should allocate data for at least one evolution even if the size of image is small.

What do you think?

Which descriptor type should I use?

Can someone explains the difference between Descriptor Type, 0-> SURF_UPRIGHT, 1->SURF 2-> M-SURF_UPRIGHT, 3->M-SURF 4-> M-LDB_UPRIGHT, 5->M-LDB

Possible bug in Compute_Main_Orientation AKAZE.cpp line 634

It is possible that keypoint not assigned to any object. In this case class_id == -1. It will cause runtime error.

VLBenchmarks code

Hi, I possibly wanted to propose some changes to akaze, but only if they are beneficial.

Would it be possible to make available in even the crudest form (minimal work on your part) the vlbenchmark/matlab code you used for comparisons in your KAZE and AKAZE papers?

Thanks,
-Ian

Find_Scale_Space_Extrema questions

I am writing an OpenCL version of the code and I have most things working in a basic manner (optimization is still needed). But when locating the extrema my implementation is locating about a 3rd less feature points and closer examination of Find_Scale_Space_Extrema in the original code I am slowing finding the subtle differences. But it has left me with some lingering questions.

First it seems that higher octave pixels position are not properly centered in regards to the original resolution. The algorithm seems to center the pixel over the top left pixel that the higher octave represents, meaning that all distance calculations seem to have a shift.

I would have expect more like this

Shouldn't there be a half pixel shift added to all the calculations for pixel position during the extrema search?

Second why does the repeat filtering only look down/up 1 level of evolution? If multiple feature points consistently show up centered in close proximity in multiple evolution (no matter how far away they are in evolution) why are they not considered the same point? It might make sense to filter any feature point clusters after sub-pixel positions are calculated.

Performance issue on iPhone

Hi Pablo,

I am trying to see if I can work with AKAZE on my mobile project, but it seems quite slow compared to ORB. I think the difference is about an order of magnitude, as OpenCV ORB extracts and matches the features in under a second, while AKAZE takes several seconds (binary descriptor). Is this expected or am I not using the library in the right way?

Feature extraction:

AKAZEOptions options;
options.descriptor = MLDB;
options.img_width = view.cols;
options.img_height = view.rows;
Mat view32;
view.convertTo(view32, CV_32F, 1.0/255.0,0);
AKAZE akazeDetector(options);
akazeDetector.Create_Nonlinear_Scale_Space(view32);
vector<KeyPoint> keypoints;
akazeDetector.Feature_Detection(keypoints);
Mat descriptors;
akazeDetector.Compute_Descriptors(keypoints, descriptors);
pair<Mat,vector<KeyPoint> > result(descriptors, keypoints);
return result;

Feature matching:

vector<Point2f> matches, inliers;
Ptr<DescriptorMatcher> matcherL1 = DescriptorMatcher::create("BruteForce-Hamming");
vector<vector<cv::DMatch> > dmatches;
matcherL1->knnMatch(firstViewFeatures.first, secondViewFeatures.first, dmatches, 2);
matches2points_nndr(firstViewFeatures.second, secondViewFeatures.second, dmatches, matches, 0.80f);
compute_inliers_ransac(matches, inliers, 2.50f, false);
vector<Point2f> points1, points2;

for (int i = 0; i < inliers.size(); i+=2)
{
    points1.push_back(inliers[i]);
    points2.push_back(inliers[i+1]);
}

return pair<vector<Point2f>,vector<Point2f> >(points1, points2);

The example images I'm working with:

Thanks

how to sort the keypoints?

considering the memory and speed, i don't need so much keypoints, so how i can sort the keypoints to get the top N ?

Error compiling akaze.mexa64

Warning: You are using gcc version '4.8.4'. The version of gcc is not supported. The version
currently supported with MEX is '4.7.x'. For a list of currently supported compilers see:
http://www.mathworks.com/support/compilers/current_release.

I am also using OpenCV- 2.4.8 on ubuntu.

I run the following in the /akaze/mex folder:
mex('akaze.cpp','-I../src/lib/','-L../build/lib/','-lAKAZE','-L/usr/local/lib/',...
'-lopencv_imgproc','-lopencv_core','-lopencv_calib3d','-lopencv_highgui','-lgomp');

The error message:
Error using mex
~/Dev/akaze/mex/akaze.cpp: In function ‘void mexFunction(int, mxArray**, int, const mxArray**)’:
~/Dev/akaze/mex/akaze.cpp:218:2: error: ‘AKAZE’ was not declared in this scope
AKAZE evolution(options);
^
......./akaze/mex/akaze.cpp:218:2: note: suggested alternatives:
In file included from /usr/local/include/opencv2/features2d/features2d.hpp:48:0,
from ~/Dev/akaze/mex/../src/lib/utils.h:12,
from ~/Dev/akaze/mex/../src/lib/AKAZE.h:14,
from ~/Dev/akaze/mex/akaze.cpp:22:
/usr/local/include/opencv2/features2d.hpp:643:20: note: ‘cv::AKAZE’
class CV_EXPORTS_W AKAZE : public Feature2D
^
In file included from ~/Dev/akaze/mex/akaze.cpp:22:0:
~/Dev/akaze/mex/../src/lib/AKAZE.h:23:9: note: ‘libAKAZE::AKAZE’
class AKAZE {
^
~/Dev/akaze/mex/akaze.cpp:218:8: error: expected ‘;’ before ‘evolution’
AKAZE evolution(options);
^
~/Dev/akaze/mex/akaze.cpp:219:2: error: ‘evolution’ was not declared in this scope
evolution.Create_Nonlinear_Scale_Space(img_32);
^

Error in make (line 9)
mex('akaze.cpp','-I../src/lib/','-L../build/lib/','-lAKAZE','-L/usr/local/lib/',...

Which parameters can I change to increase my detected keypoints?

Hi there,

Which parameters would I change if I want to increase the number of my keypoints? I realize, that in doing so, I will likely decrease sensitivity, but I'm willing to experiment with that.

It seems that the average of my images (500px x 500px) yield around ~200 to ~300 keypoints. I'm looking to see if my matching gets better if I'm able to get this number up to ~1000.

Any pointers?

Cheers,
Brett

cv::ORB::create() called with wrong arguments?

I am using OpenCV 2.4.11, and I think the argument list for cv::ORB::create() needs to be changed as in the following (you are missing a score type argument), but I don't know if this will actually change the results (probably not).

Index: src/akaze_compare.cpp
===================================================================
--- src/akaze_compare.cpp       (original)
+++ src/akaze_compare.cpp       (new)
@@ -154,7 +154,7 @@
 #else
   cv::Ptr orb = cv::ORB::create(ORB_MAX_KPTS, ORB_SCALE_FACTOR, ORB_PYRAMID_LEVELS,
 #endif
-    ORB_EDGE_THRESHOLD, ORB_FIRST_PYRAMID_LEVEL, ORB_WTA_K, ORB_PATCH_SIZE);
+    ORB_EDGE_THRESHOLD, ORB_FIRST_PYRAMID_LEVEL, ORB_WTA_K, cv::ORB::HARRIS_SCORE, ORB_PATCH_SIZE);

Akaze Flip Invariance

Is it possible to make Akaze flip invariant when using the MLDB/MLDB-Upright descriptor? If so, what is the best approach to implement this?

Question: Scharr derivatives in AKAZE

Hi Pablo,

I'm working on performance improvements of OpenCV version of your code. Thanks a lot your code, it is nicely readable. I have a few questions however:

1. Why does the Scharr needs to be computed twice? First here for computing diffusivity and then for computing Hessian determinant here. First is standard 3x3 Scharr, the second is using sigma-sized kernels. Would it be possible to compute it just once (either using sigma-sized or 3x3 kernel)?

2. Would it be possible to use only standard 3x3 Scharr for computing Hessian Determinant? There is a huge possible speedup.

3. Before processing the image is converted to floats. Could some parts use just bytes, without affecting accuracy too much?

Have a nice day.

Cheers,
Jiri

Replace OpenMP for TBB

In this way porting to Android will be much easier

CUDA_AKAZE returns multiple instances of the same keypoint

I am trying to use donlk/cuda_akaze to detect features on an NVidia Jetson Nano (4GB version). I have managed to compile the library files using my own makefile to incorporate the source files in my own project. It runs, but when I call

evolution1.Create_Nonlinear_Scale_Space(greyLeft);
evolution1.Feature_Detection(kpts1_akaze);
evolution1.Compute_Descriptors(kpts1_akaze, desc1_akaze);

kpts1_akaze is filled with multiple copies of the same keypoint and desc1_akaze is filled with multiple copies of the same descriptor. The number of copies seems to be around the expected value of found keypoints.

I am using CUDA 10.2 and OpenCV 4.1.1.

It runs perfectly fine on my laptop, which contains a quadro P1000 compiled in visual studio 2017 using CUDA 10.2 and OpenCV 4.5.0.

Does opencv 3.1 provide flann based matching with CUDA

I have noticed that openCV 3.1 has a CUDA library that is able to do Brute Force Matching, but I did not find any code to apply flann based matching using CUDA.

GPU Version

Any plans on having a GPU accelerated version of the algorithm?

Question about discretization

How is the discretization due to subsampling accounted for in the nlp steps? For each increasing octave derivates are approximated with increasing step lengths in terms of the original image, which should lead to more diffusion than expected, given that the diffusion steps seem not to be correspondingly adjusted for. It strikes one as odd that higher octaves need more diffusion steps. The exponential increase in scale and exponential decrease in image size should cancel each other out.

Make Issue: OutputArray reference declaration

Compile issue as of 816d8ea

Error sample on Ubuntu 13.10 64 bit:

user@user ~/g/akaze (master)> mkdir build
user@user ~/g/akaze (master)> cd build/
user@user ~/g/a/build (master)> cmake ..
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Found OpenMP: -fopenmp  
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.4") 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/git/akaze/build
user@user ~/g/a/build (master)> make
Scanning dependencies of target AKAZE
[ 14%] Building CXX object CMakeFiles/AKAZE.dir/src/lib/AKAZE.cpp.o
In file included from /home/user/git/akaze/src/lib/AKAZE.h:19:0,
                 from /home/user/git/akaze/src/lib/AKAZE.cpp:23:
/home/user/git/akaze/src/lib/nldiffusion_functions.h:34:50: error: cannot declare reference to ‘cv::OutputArray {aka const class cv::_OutputArray&}’
 void compute_derivative_kernels(cv::OutputArray& kx_, cv::OutputArray& ky_,
                                                  ^
/home/user/git/akaze/src/lib/nldiffusion_functions.h:34:72: error: cannot declare reference to ‘cv::OutputArray {aka const class cv::_OutputArray&}’
 void compute_derivative_kernels(cv::OutputArray& kx_, cv::OutputArray& ky_,
                                                                        ^
make[2]: *** [CMakeFiles/AKAZE.dir/src/lib/AKAZE.cpp.o] Error 1
make[1]: *** [CMakeFiles/AKAZE.dir/all] Error 2
make: *** [all] Error 2
user@user ~/g/a/build (master) [2]> 

The source code should be made a little change in Ubuntu 16.04

On Ubuntu 16.04, if you installed opencv from repository by apt such as apt install libopencv, you should change some code in file src/akaze_* and src/lib/utils.cpp
such as
#include <opencv2/calib3d.hpp>
#include <opencv2/imgproc.hpp>
to
#include <opencv2/calib3d/calib3d.hpp>
#include <opencv2/imgproc/imgproc.hpp>.

Use Compute_Descriptors on an existing vector<KeyPoint>?

Hi, and thank you for making this code available. I am trying to split out the Compute_Descriptors function from the rest, so that i can use it on existing Keys, found in another function. (using this code also).
I get keypoints and descriptors. Then I filter out some of the keypoints, and now i want to find descriptors of the remaining Keypoints. I have this function:

void Akaze::DetectDesciptorsOnly( cv::Mat &returnDesc, vector<cv::KeyPoint> Keys)
{
	//set up 
	if (bFirstLoopDescrip == false)
	{
		evolutionDescrip = new AKAZE(optionsDescrip);
		bFirstLoopDescrip = true;
	}
	cv::Mat desc;
	evolutionDescrip->Compute_Descriptors(Keys, desc);
	std::cout << "des " << desc.rows << std::endl;
	desc.copyTo(returnDesc);
}

But it always returns zero. The keypoint array has around 900 points going in. Where am i going wrong here? thanks!

Port AKAZE to OpenCV and make pull request

Conflict with (old) OpenCV

I'm trying to compile AKAZE but there's a conflict between definition of SURF in enum type and openCV cv::SURF class :

Scanning dependencies of target AKAZE
[ 14%] Building CXX object src/CMakeFiles/AKAZE.dir/lib/AKAZE.cpp.o
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp: In member function ‘void AKAZE::Find_Scale_Space_Extrema(std::vector<cv::KeyPoint>&)’:
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:271:69: error: reference to ‘SURF’ is ambiguous
In file included from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.h:13:0,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:9:
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZEConfig.h:43:3: error: candidates are: DESCRIPTOR_TYPE SURF
In file included from /usr/include/opencv2/opencv.hpp:52:0,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZEConfig.h:12,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.h:13,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:9:
/usr/include/opencv2/features2d/features2d.hpp:392:20: error:                 class cv::SURF
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp: In member function ‘void AKAZE::Compute_Descriptors(std::vector<cv::KeyPoint>&, cv::Mat&)’:
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:551:10: error: reference to ‘SURF’ is ambiguous
In file included from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.h:13:0,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:9:
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZEConfig.h:43:3: error: candidates are: DESCRIPTOR_TYPE SURF
In file included from /usr/include/opencv2/opencv.hpp:52:0,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZEConfig.h:12,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.h:13,
                 from /home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:9:
/usr/include/opencv2/features2d/features2d.hpp:392:20: error:                 class cv::SURF
/home/romuald/Prog/AKAZE/akaze/src/lib/AKAZE.cpp:539:10: warning: enumeration value ‘SURF’ not handled in switch [-Wswitch]
make[2]: *** [src/CMakeFiles/AKAZE.dir/lib/AKAZE.cpp.o] Erreur 1
make[1]: *** [src/CMakeFiles/AKAZE.dir/all] Erreur 2
make: *** [all] Erreur 2

In order to compile I had to modify AKAZEConfig in this way :

/// AKAZE Descriptor Type
enum DESCRIPTOR_TYPE {
  SURF_UPRIGHT = 0, ///< Upright descriptors, not invariant to rotation
  DESC_SURF = 1,
  MSURF_UPRIGHT = 2, ///< Upright descriptors, not invariant to rotation
  MSURF = 3,
  MLDB_UPRIGHT = 4, ///< Upright descriptors, not invariant to rotation
  MLDB = 5
};

And replace SURF by DESC_SURF in AKAZE.cpp . Perhaps a better solution is to use an enum class or a namespace.

I only got 2.3.1 version of OpenCV but that's standard version on stable release of debian at this time. It also means that it cannot compile akaze_compare.cpp (openCV 2.3.1 does not have BRISK) but features and match compile fine.

Problem building this version of Kaze with OpenCV 2.4

Hello,

I am trying to compile it on Ubuntu 12.04 after having installed the latest OpenCV from (https://github.com/Itseez/opencv.git) but I get a problem :

cmake.. did work :
-- Configuring done
-- Generating done
-- Build files have been written to: /home/kaze/build

but when doing the "make" things go wrong :
root@kazedev:/home/kaze/build# make
Scanning dependencies of target KAZE
[ 14%] Building CXX object src/CMakeFiles/KAZE.dir/lib/KAZE.cpp.o
/home/kaze/src/lib/KAZE.cpp:35:1: error: reference to âKAZEâ is ambiguous
/home/kaze/src/lib/KAZE.h:42:7: error: candidates are: class KAZE
/usr/local/include/opencv2/features2d.hpp:901:20: error: class cv::KAZE
/home/kaze/src/lib/KAZE.cpp:35:1: error: âKAZEâ does not name a type
/home/kaze/src/lib/KAZE.cpp:48:1: error: reference to âKAZEâ is ambiguous
/home/kaze/src/lib/KAZE.h:42:7: error: candidates are: class KAZE
/usr/local/include/opencv2/features2d.hpp:901:20: error: class cv::KAZE
and many more errors...

OpenCV seems to be installed correctly. Do you see what could possibly lead to these errors ?

Thanks a lot in advance for your reply.

Best regards

Flo

Finding scale space extrema

Hi,

I'm curious about the lines 333-334 and 338-339 in AKAZE.cpp. The addition + .5*(ratio-1.0) to the accepted points are compared with incoming points that do not have that extra term added to them. Is this intentional? I'm curious since I'm working on a GPU version (with Mårten Björkman who has previously posted here, and Alessandro Pieropan). The idea is that the GPU version should produce the same results as the CPU version, which imposes constraints on the extrema detection and filtering which are hard to do in parallel. In particular the lines mentioned above are giving me trouble when performing the filtering in parallel.

The GPU version can of course be made more efficient if a different result compared to the CPU version can be accepted, but I figured it might be worth having an identical version as well.

Niklas

Cuda-Akaze not building

When I run the cmake .. for cuda_akaze, the bin folder is not created. and the after make there is no .so files.

Please let me know the correct steps to install cuda_akaze, and also the installation on python.

Possible bug in downsample_image

I think there's a bug in downsample_image.

the code :

void downsample_image(const cv::Mat& src, cv::Mat& dst) {

  int i1 = 0, j1 = 0, i2 = 0, j2 = 0;

  for (i1 = 1; i1 < src.rows; i1+=2) {
    j2 = 0;
    for (j1 = 1; j1 < src.cols; j1+=2) {
      *(dst.ptr<float>(i2)+j2) = 0.5*(*(src.ptr<float>(i1)+j1))+0.25*(*(src.ptr<float>(i1)+j1-1) + *(src.ptr<float>(i1)+j1+1));
      j2++;
    }

    i2++;
  }
}

could cause an out of range access when source image has even dimensions.
For example using a 2x2 image access (in col index ) are : j1 = 0 1 2 and last index is not in a valid range. If height dim is odd, access is done (if matrix rows are contigous in memory) on the next row (maybe not something wanted but still safe) but if height dim is even, access is out of image range and can cause segfault in the worst case.

I did not see that input image are enlarged before to avoid this problem so I think there's a potential bug here.

use c++11 std::to_string

This might be trivial, but wouldn't it be better (safer) to use c++11 std::to_string if user choose to compile with c++11?

Existence of patent for A-KAZE and KAZE

Hi,

I would like to make another open-source implementation of A-KAZE for Boost library (Boost license). Would that infringe any patent or be otherwise not okay by authors?

I was also thinking if it is okay to make KAZE implementation as well, to provide a little bit of variety (main concern is M-SURF descriptor, which is a derivative of patented SURF descriptor).

I believe Adrien responded being okay about it, sorry if I am needlessly bothering you.

do you have a plan to integrate this in the opencv featured2 module?

http://code.opencv.org/projects/opencv/wiki/How_to_contribute