The results of some operations/computations are not the same in debug and release mode. (Bug #1383)


Added by pol - over 13 years ago. Updated almost 13 years ago.


Status:Cancelled Start date:
Priority:High Due date:
Assignee:Vadim Pisarevsky % Done:

0%

Category:features2d
Target version:2.4.0
Affected version: Operating System:
Difficulty: HW Platform:
Pull request:

Description

We encounter following problems working with feature detection and tracking (OpenCV built with MinGW)
1. The detected features are not always the same in debug and release mode.
2. The matches are not always the same in debug and release mode
3. There are numerical differences in feature coordinates after cornerSubPix for debug and release mode (usualy < 10e-4)

The problems are reproducable. We have observed them with OpenCV 2.2.0 and 2.3.1 and following versions of MinGW/GCC toolchain:
1. GCC 4.6.1
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingwdir/mingw/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdc
xx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.1 (GCC)

2. GCC 4.4.1, TDM
Target: mingw32
Configured with: ../../gcc-4.4.1/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-nls --disable-win32-regis
try --enable-libgomp --enable-cxx-flags='-fno-function-sections -fno-data-sections' --disable-werror --enable-threads --disable-symvers --enable-version-specifi
c-runtime-libs --enable-fully-dynamic-string --with-pkgversion='TDM-2 mingw32' --enable-sjlj-exceptions --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php
Thread model: win32
gcc version 4.4.1 (TDM-2 mingw32)
3. I also tried GCC 4.4.0 downloaded from Nokia QT page

Build details:
1. OpenCV 2.2.0 (GCC 4.4.0, GCC 4.4.1)
The OpenCV was build using default configuration. Then I disabled the fast-math flag in Release mode, then SSE flags but it didn't help.
2. OpenCV 2.3.1 (GCC 4.4.1, GCC 4.6.1)
I've built it with
- default config
- without SSE flags
- without SSE flags and O2 optimization on
without SSE flags and -O1 optimization on

We compare the results with MSVC 2010 and the results were always the same in debug and release mode for Microsoft compiler. The same applications build with GCC 4.6.x but under Linux also works without problems. As the results are not reliable and we could find the reason we had to switch to MS compiler.

I attached a very small aplication which detects 3 features (using GoodFeaturesToTrack detector) in a small image (image and the corresponding mask is also attached).Results for cv 2.3.1 (GCC 4.6.1) on my PC are:
1. Debug Mode:
[158, 85]
[123, 58]
[132, 68]

2. Release Mode:
[158, 85]
[123, 58]
[108, 52]

These problems follows us since few weeks so we'd realy appreciate your help. Thanks in advance!


detector_test.cpp (1.2 kB) pol -, 2011-09-21 11:39 am

subimg.bmp (26.1 kB) pol -, 2011-09-21 11:39 am

submask.bmp (26.1 kB) pol -, 2011-09-21 11:40 am


Associated revisions

Revision f50a8299
Added by Roman Donchenko over 11 years ago

Merge pull request #1383 from pengx17:2.4_clblas

History

Updated by Vadim Pisarevsky over 13 years ago

Since with GCC on Linux and Visual Studio you get correct results, I'm afraid, this is a problem of MinGW, which, as we found, often has some glitches with code generation.

All you can do is to play with various flags. Try "-ffloat-store" for example, try to disable sse math.

Also, in general it's not guaranteed that in Debug and Release you will always get the same features. Since the algorithm uses floating-point operations, including comparisons to dynamically computed floating-point thresholds, you could get different comparison results in Debug and Release.

Many OpenCV feature descriptors can be computed on user-provided keypoints. If the equality of results is important to you, you can use some purely integer algorithm for detecting keypoints, such as FAST, and then compute descriptors for these very keypoints.

  • Status changed from Open to Done
  • (deleted custom field) set to wontfix

Updated by Andrey Kamaev almost 13 years ago

  • Status changed from Done to Cancelled
  • Target version set to 2.4.0
  • Category set to features2d

Also available in: Atom PDF