Bug in LBP (Bug #3393)

Added by Gil Levi over 11 years ago. Updated almost 10 years ago.

Status:Done Start date:2013-11-24
Priority:Normal Due date:
Assignee:Kirill Kornyakov % Done:

100%
Category:features2d
Target version:2.4.10
Affected version:2.4.0 - 2.4.8 Operating System:Windows
Difficulty:Easy HW Platform:x64
Pull request:

Description

Hi,

In the last couple of hours, I worked closely with LBP in OpenCV and compared it with the original implementation in Matlab. There was a slight difference in the results I got, so I looked more closely at the code.

I found the following bug. In the lines:

float x = static_cast<float>(-radius * sin(2.0*CV_PI*n/static_cast<float>(neighbors)));
float y = static_cast<float>(radius * cos(2.0*CV_PI*n/static_cast<float>(neighbors)));
the roles of x and y are flipped. It should be :

float y = static_cast<float>(-radius * sin(2.0*CV_PI*n/static_cast<float>(neighbors)));
float x = static_cast<float>(radius * cos(2.0*CV_PI*n/static_cast<float>(neighbors)));
As in Matlab it's:

spoints(i,1) = -radius*sin((i-1)*a); %y
spoints(i,2) = radius*cos((i-1)*a); %x
The reason is obvious - x corresponds to the cos value of the angle and y corresponds to the y value of the angle. After changing the code, the results in Matlab and OpenCV were the same.

History

#1
Updated by Gil Levi over 11 years ago

  • Assignee set to Gil Levi

#2
Updated by Steven Puttemans over 11 years ago

Are you working on your own pull request or you need some help? Once you got it, feel free to post it here!
Link to discussion on forum : http://answers.opencv.org/question/24292/bug-in-lbp/

  • Difficulty set to Easy
  • Target version set to 2.4.8
  • Status changed from New to Open

#4
Updated by Steven Puttemans over 11 years ago

Fix made and merged by @berak!

  • % Done changed from 0 to 100
  • Status changed from Open to Done
  • Assignee deleted (Gil Levi)

#5
Updated by Gareth Owen about 11 years ago

Steven Puttemans wrote:

Fix made and merged by @berak!

Unfortunately, this breaks backwards compatibility with older recognizers. So if I train a recognizer on 2.4.5 and save the YML, then load it on 2.4.8, it loses the ability to recognize anything. I think this is a bigger deal than Matlab compatibility in intermediate representations - there's no definitive order of rotation in calculating LBPH.

#6
Updated by Andrew Senin about 11 years ago

Kirill, please comment if it is okay that compatability with 2.4.5 is broken? Shall we open a new issue on this?

  • Assignee set to Kirill Kornyakov
  • Affected version changed from 2.4.7 (latest release) to 2.4.8 (latest release)
  • Status changed from Done to Open
  • Category set to features2d
  • Target version changed from 2.4.8 to 2.4.9

#7
Updated by Alexander Smorkalov almost 11 years ago

  • Target version changed from 2.4.9 to 2.4.10

#8
Updated by Vadim Pisarevsky almost 10 years ago

as I see, now the bug has been fixed

  • Status changed from Open to Done
  • Affected version changed from 2.4.8 (latest release) to 2.4.0 - 2.4.8

Also available in: Atom PDF