Recent changes to bugs

Bad OpenMP detection with some compilers

2012-09-26T13:15:44Z

I encountered problems with the OpenMP detection routine from the CMakeLists.

I had problem with the Intel Compiler on linux, and now I have the same problem when compiling on MacOSX 10.8 with the default compiler (clang).
CMake provides the necessary find_package for OpenMP, and it solves the issue.

More specifically, replacing line 273 to 306 of CMakeLists.txt with much simpler :

# check for OpenMP
find_package(OpenMP)
if(OPENMP_FOUND)
message(STATUS "Enabling OpenMP support")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${OpenMP_EXE_LINKER_FLAGS}")
else()
message(STATUS "Disabling OpenMP support")
endif()

does the trick.

Compilation goes on for MacOSX 10.8/clang (no openmp found).
Also tested on linux, where openmp is activated correctly.
Did not yet try with Intel Compiler though.

Seems safer to me as it tests more flags than current libsiftfast, and also actually runs a try_compile with OpenMP code to validate.

No idea about the "gomp" library that is linked in the libsiftfast CMakeLists, and does not come out of the FindOpenMP.cmake file.
Looking at http://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html#Enabling-OpenMP
it seems that the compiler flag is enough and triggers automatic linking to OpenMP lib on gcc.

Assertion fails

2011-07-22T12:49:15Z

Hello,

I get the following error using libsiftfast:

libsiftfast-1.2-src/libsiftfast.cpp:1645: void PlaceInIndex(float*, float, float, float, float): Assertion `newrow >= -1 && newrow < 4 && neworient >= 0 && neworient <= 8 && rfrac >= 0 && rfrac < 1' failed.

I'll try to look into it in more detail...

Segmentation fault on small images

2010-05-16T14:51:45Z

Siftfast has a tendency to crash on small images. I've attached a random generated image that is 28 by 1 pixel image that crashes both version 1.2 and revision 52.

The backtrace from GDB is:
(gdb) bt
#0 0x0000000000406ab4 in _mm_loadu_ps (.omp_data_i=0x7fffe7aa38e0) at /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/xmmintrin.h:906
#1 ConvVerticalFast.omp_fn.3 (.omp_data_i=0x7fffe7aa38e0) at /home/pcmoen/Source/libsift-trunk/libsiftfast.cpp:964
#2 0x000000000040752c in ConvVerticalFast (image=0x6a5220, kernel=<value optimized out>, ksize=<value optimized out>) at /home/pcmoen/Source/libsift-trunk/libsiftfast.cpp:911
#3 0x0000000000407c81 in GaussianBlur (imgdst=0x6a5220, image=0x6a5220, fblur=<value optimized out>) at /home/pcmoen/Source/libsift-trunk/libsiftfast.cpp:648
#4 0x0000000000409815 in GetKeypointsInternal (porgimage=<value optimized out>) at /home/pcmoen/Source/libsift-trunk/libsiftfast.cpp:330
#5 0x000000000040a64f in main (argc=<value optimized out>, argv=<value optimized out>) at /home/pcmoen/Source/libsift-trunk/siftfast.cpp:121

Using large image will crash the DLL

2010-04-06T10:18:40Z

Hi,
If you try to call "GetKeypoints( );" with a large image, the DLL will crash without any message. The bug is present from version 1.0 until 1.2 included!

Are you aware of this behavior?
Smaller images (2000px x 3000px) will also crash.

Regards

May be a buf of GaussianBlur

2009-12-25T09:18:02Z

I find that the result of SSE GaussianBlur function is not very perfect comparing to the result of OpenCV cvSmooth.

I read image from cvLoadImage and convert it to ImageSt in libsiftfast. Then I use GaussianBlur like following:
----------------
GaussianBlur(dimage, image, sqrtf(InitSigma*InitSigma - fnewscale*fnewscale));
----------------

I also convert the result back to OpenCV image structure IplImage and then show the image.

The image smoothed by GaussianBlur in libsiftfast is not very perfect comparing to the result of OpenCV cvSmooth. I think there may be some bugs in SSE GaussianBlur.

I attach two pictures to show this difference. Picture after_opencv_cvsmooth.jpg is smoothed by OpenCV cvSmooth and picture after_Gaussianblur.jpg is smoothed by libsiftfast GaussianBlur.