Ask Your Question

Robby's profile - activity

2020-10-25 06:33:23 -0600 received badge  Nice Question (source)
2019-11-30 11:45:31 -0600 commented answer Building OpenCV problem : 'ptrdiff_t' : is not a member of 'std'

@berak: It is stupid to down vote an answer while you don't provide a better solution. For me setting _GLOBAL_USING 1 so

2018-12-15 11:10:44 -0600 answered a question Building OpenCV problem : 'ptrdiff_t' : is not a member of 'std'

I had the same problem on one Windows installation but not on another. So I compared the Visual Studio include files and

2015-03-21 07:43:13 -0600 answered a question OpenCV Crash C000001D - Severe problem with a solution proposal

It has nothing to do with the windows version.

I wrote that I use two different computers. It depends if the processor supports SSE2 instructions or not.

The crash may happen on any Windows version.

2014-07-14 05:56:04 -0600 received badge  Student (source)
2014-07-13 13:25:42 -0600 asked a question How to replace libpng, libtiff etc with GDI+ Bitmap (Load into cv::Mat via GDI+)

I'm working on a project that uses OpenCV and Tesseract. Both libraries are based on libpng, libtiff, libjpeg, etc.. to load/save image files.

But Tesseract (based on Leptonica) uses older versions of these libraries which have incompatible parameters. So I cannot use the same image libraries for both: OpenCV an Tesseract.

So if I compile my project dynamically, I will have to deliver a bunch of DLLs with my project. And if I compile statically I produce a huge output file blown up by several megabytes.

This is UGLY. I don't want that.

Another problem is that nearly all open source projects - mainly developed in Linux/MAC world - do not support Unicode if compiled on Windows. Internally they all pass a std::string to fopen(). On Linux a workaround may function: Encoding the path with UTF8, but on Windows it will not. So a Japanese user cannot open an image file in a folder with a Japanese name. While Microsoft already in the early 1990's made big efforts to convert the entire Windows NT operating system to be 100% Unicode compatible, the majority of open source projects (like libpng) 20 years later still does not support passing a path via std::wstring.

The OpenCV commands imread() and imwrite() must NOT be used on Windows if you want to create an international project!

So, what I want is: Eliminate libtiff, libpng, libjpeg completely from my project:

In OpenCV comment out:

// #define HAVE_JASPER
// #define HAVE_JPEG
// #define HAVE_PNG
// #define HAVE_TIFF
etc..

In Tesseract / Leptonica:

#define  HAVE_LIBJPEG   0
#define  HAVE_LIBTIFF   0
#define  HAVE_LIBPNG    0
#define  HAVE_LIBZ      0
#define  HAVE_LIBGIF    0
#define  HAVE_LIBUNGIF  0
etc..

..and use GDI+ instead that is part of the Windows operating system and that supports loading/saving BMP, TIF, PNG, JPG, GIF. And GDI+ is Unicode compatible.

I know that this can be done with a few lines of code, but such a usefull class is missing in the OpenCV project. My first trials showed that this is not as trivial as it seems on the first look because a lot of conversions have to be done.

I wrote a ready-to-use class for that purpose. You can download it here: OpenCV / Tesseract: How to replace libpng, libtiff etc with GDI+ Bitmap (Load into cv::Mat via GDI+)

I hope my useful class will be included into the OpenCV project for all Windows users in the world.

2014-06-15 15:10:07 -0600 asked a question OpenCV Crash C000001D - Severe problem with a solution proposal

Hello

I built OpenCV with CMake for Visual Studio letting all the settings (checkboxes) in CMake at its default.

I wrote a small test application and at the first look all worked fine.

But then I compiled as release and the same application crashed. The Crash happened when loading opencv_core248.dll into my process. Error code: 0xC000001D. This happened on my Windows XP computer.

Then I tested on another computer with Windows 7 and - really surprisingly - both work fine: The debug and the release version!

Windows XP, release -> Crash

Windows XP, debug -> OK

Windows 7, release -> OK

Windows 7, debug -> OK

As Visual Studio gave me no clue what was wrong, I ran Dependency Walker which told me that all dependencies were OK. Then I ran ProcessMonitor to see if any error happened while loading the DLL, but all was fine. So what is wrong??

To ever find a crash if the debug version is fine but the release version crashes you must be an experienced programmer! There is no way to single step through the C++ code because the DLL did not even load into the process!

So finally I started my program in OllyDebug which stopped at this command:

MOVQ .... ,MMX0

Invalid instruction.

This happened in line 4860 in persistence.cpp:

*info = *_info;

where info is a CvTypeInfo struct. Visual Studio inserts MMX instructions to copy the content of one struct to another!!! And this happens while the DLL is initializing and results in a crash.

My AMD Sempron processor on my Windwos XP did not understand this instruction.

It is a severe design error that the default settings used for CMake insert instructions that may result in a crash on some processors!!

Several projects are based on OpenCV like for example the Sikuli project. When you download the Sikuli project and run it on an AMD Sempron it will crash for the same reason: It is wrongly compiled, too.

The default configuration for CMake generates VCPROJ files with

Enable Enhanced Instruction Set = Streaming SIMD extensions 2 (/arch:SSE2)

under C/C++ -> Code generation in the project settings.

After turning this off in all projects and compiling the whole world anew, all worked fine.

How is it possible that the default options of OpenCV enable code that is not compatible with all processors??

This is a severe misconfiguration that must be changed urgently in future OpenCV versions.

The SSE instructions must be turned off by default. And anyone who enables this feature must be warned that the code will not run on all processors and may result in a total crash that is nearly impossible to find for beginners.