gpu::Orb is not determinist (Bug #2208)

Added by mathieu letombe 10 months ago. Updated 8 months ago.

Status:Cancelled Start date:2012-07-27
Priority:Normal Due date:
Assignee:Vladislav Vinogradov % Done:

0%
Category:gpu
Target version:-
Affected version: Pull request:

Description

Hi,

gpu::orb is not always giving the same result for the same image on the same card in the same run.
I did some code to show it, it uses a window 7 public image.

I'm using the version 2.4.2 rebuilt with Ipp, Cuda 4.2 and Qt in visual 10 pro 64 bits on win 7 64.
I tested it on a quadro NVS 295, Quadro 2000 and Tesla C1060. If you run it several times you will see that the diffs are not always the same.
Some keypoints disappear, some appear.

Thank's for your work,
Mathieu.

BugGpuOrbNotDeterminist.cpp (1.5 kB) mathieu letombe, 2012-07-27 10:40 am

History

#1
Updated by mathieu letombe 10 months ago

I did some more tests.

In the previous code I did:
gpu::GpuMat gpuVide;
gpuOrb1(gpuImg, gpuVide, gpuVkp[i], gpuVDesc[i]);
as the const GpuMat& mask (gpuVide) is referred as optionnal in the doc, I let it empty like in the cpu orb.

Now I fill it with:
Mat mask = Mat::ones(img1.rows, img1.cols, CV_8U);
gpu::GpuMat gpuVide;
gpuVide.upload(mask);

And now there are 0 diff on the 2 Quadros, but still diffs on the tesla....???!!!

#2
Updated by Vladislav Vinogradov 10 months ago

It's not actually a bug.

The algorithm performs sorting of points according to their response. Some points have equal responses, but their position in initial array differs for different launches due to detector's asynchronous work. So after sorting their final position in result will be different (sorting algorithm is not stable).

  • Assignee changed from Anatoly Baksheev to Vladislav Vinogradov

#3
Updated by mathieu letombe 10 months ago

No it's not just sorting, some keypoints disappear, some appear.
The code I sent you can detect differences just because of sorting problems, but I noticed keypoints disappearing and other appearing with the debugger.

#4
Updated by mathieu letombe 10 months ago

Continuing my tests:
I tried to see if keypoints are more consistent between cpu and gpu if a filled mask is given as a parameter.

But I found another bug (or strange behaviour) in both cpu and gpu orb.
I created a mask of CV_8U filled up with 1 and with the same size as the image.
Then both functions return only the first octave keypoints. The mask has to be filled up with 0xFF.

When I fill it up with 0xFF I've got the good number of keypoints and all the octaves.
They are approximately consistent for the first octave, but after that ... no relation.

#5
Updated by Vladislav Vinogradov 10 months ago

The algorithm builds image and mask pyramids using resize function with linear interpolation. If mask contains 1 after resize it will contain zeros due interpolation.

#6
Updated by mathieu letombe 10 months ago

Ok, I understand now.
I had 0 diffs on the 2 quadros because it was limited to the first octave.

#7
Updated by Vladislav Vinogradov 10 months ago

Points can appear and disappear due filtration by its number. After sorting algorithms leaves only the first n points (depends on the parameters).
Due to inconsistent point position after sorting, algorithm leaves different points for different launches.

#8
Updated by mathieu letombe 10 months ago

Some keypoint appear and disappear and it's not due to the sorting by the Harris response.
I'd like to attach a screen copy of my debugger but I can't find the way to do it.

#9
Updated by Vladislav Vinogradov 8 months ago

ORB uses FAST detector for keypoint position.
FAST detector always returns the same points for the same image, but their position in output array differs.
ORB performs sorting on FAST output and leaves only the first n points.
Keypoints appear and disappear due to this filtration.

  • Status changed from Open to Cancelled

Also available in: Atom PDF