[GSOC] Speeding-up AKAZE, part #3#9249
Conversation
|
Notice that 1a4c898 actually slows things down. I can't really explain that. edit: Of cause that I have removed that hack, it is better to use L2, which is used in the original algorithm. But I'm just curious, why it runs slightly slower. maybe it has got just negligible impact + measuments fluctuations? |
|
@hrnr, thank you, cool results! Are you going to do any more commits or it can be reviewed and integrated? |
|
Yes, I'm planning to optimize further at least non-linear diffusion and Scharr kernels with nonstandard sigmas. #8951 is ready for merge, it improves CPU perf by ~2.0x and implements basic OCL support. |
|
ok, thanks! as we are preparing 3.3 now, perhaps, it makes sense to merge something now |
|
👍 |
* incorporade finding of extremas and subpixel refinement from Hideaki Suzuki's fast_akaze (https://github.com/h2suzuki/fast_akaze) * use opencv parallel framework * do not search for keypoints near the border, where we can't compute sensible descriptors (bugs fixed in ffd9ad9, 2c53895), but the descriptors were not 100% correct. this is a better solution this version produces less keypoints with the same treshold. It is more effective in pruning similar keypoints (which do not bring any new information), so we have less keypoints, but with high quality. Accuracy is about the same.
* fix bug in subpixel refinement * see commit db3dc22981e856ca8111f2f7fe57d9c2e0286efc in Pablo's repo
* store just keypoints positions * store positions in uchar mask for effective spatial search for neighbours * construct keypoints structs at the very end
|
rebased and remowed the fixup commit. |
* win32 has lower accuracy
|
build failed on win32, which seems to have a slightly lower accuracy. I have lowered the treshold a bit. BTW Do you have idea why buildbot scheduled a win32 build? These builders has not been scheduled ever before for this PR. |
|
Some builders are optional on precommit checks. We observed that:
|
|
Testdata are an omission, but now I'm not sure if it is wise to have tests like these at all. For descriptors test the exact number of keypoints must be the same, which might be problematic as everything in AKAZE is done in floats. Detector test seems to be quite fine though. What is the approach to these magic values controlling tests? Shouldn't we drop them (at least for AKAZE) and rely only on invarience tests, which don't control any magic values? I'll check the problem with valgrind. |
|
Agree, current tests look strange and currently they are broken. I will take a look on them. |
|
@hrnr Valgrind issue: there are untouched last two bits of descriptor: 61 bytes is 488 bits, but MLDB [changes] 486 bits only. |
|
Lets put it in and fix remaining issues. |
cc: @bmagyar
This is currently based on #8951. I will rebase on master, once it gets in.
Currently this contains reworked version of finding scale space extremas. Speed up for images with lots of keypoints is ~3.6x.