psoriasis's profile - activity

This is an addendum from yesterday's post before I tried VS 2015 and found the same issue. A console app compiled using VS2013 or VS2015 using opencv 3.1.0 works fine form the command line but fails with memory errors under Visual C++. The program as originally developed under opencv 2.4.10 and had not problem under VS 2013

=== This is true for both release and debug builds. i built it, a x64 console app, under Visual Studio 2013. Using process explorer, I can see that I have the exact same command line (i.e. exact same app and args) and working directory for the exe launched via VS and manually from the command line. I can see it's using the same expected libraries (e.g. opencv_world310d for debug).

The opencv 3.1.0 was directly from the download (I didn't build it)

I'm running under Win10 x64.

Though it runs fine directly for the command line, in VS it blows up in the repeat function: First-chance exception at 0x00007FFFB5CF1F08 in HSV.exe: Microsoft C++ exception: cv::Exception at memory location 0x0000008AC80FB010.

That is not the the first opencv routine the program ran so...I'm baffled.

I copyied the repeat source code (out of copy.cpp) and made a repeata function out of it that I compiled and called with my app and that worked but then it blew up later on another opencv call.

If I hadn't had this running constantly for months under opencv 2.4.10 (Under VS2012)* or if it didn't run fine under both debug and release modes (using 3.1.0) outside VS 2013, I'd just chalk it up to a memory error elsewhere that just happen to finally make itself know but given this context I'm thinking it has something to do with the VS2013 environment but I don't know what to do about it.

I took my errant VS2013 project and just changed it so that it linked (and loaded) the 2.4.10 (debug) libs/dlls and can run without any problems So, it seems that just the fact that the project is linking and load 3.1.0 vs 2.4.10 libs/dlls is enough to make it crash but only in the VS2013 IDE(but the same executable and context run just fine from the command line)

A command line app running under Win10 x64.

Using opencv 2.4.10, the console app works both in and outside of the VS2013 IDE (i.e. from a command line).

However, using opencv 3.1.0, after rebuilding the same code under VS2013 IDE, the same app will fail when executing with VS2013 (but does work from a command line)

The errors are always some sort of memory error and always associated with lots of opencv routines.

Note, I have both 2.4.10 and 3.1.0 dlls paths on the path (w/r t their respective build/x64/vc12/bin dirs). There are no DLLS common to both versions of opencv (so there's no possibility of loading the wrong DLL and I can see that it's all correct in process explorer)

So, the only difference between the opencv 2.4.10 and 3.1.0 for the build is one specifies the 2.4.10 build/x64/vc12/lib files to link against while the 3.1.0 the same dir in the 3.1.0 opencv dir tree and the libs specified are also different as per the libs that exist in the build/xt4/vc12/lib:

opencv_world310d.lib

vs

opencv_core2410d.lib opencv_imgproc2410d.lib opencv_highgui2410d.lib opencv_ml2410d.lib opencv_video2410d.lib opencv_features2d2410d.lib opencv_calib3d2410d.lib opencv_objdetect2410d.lib opencv_contrib2410d.lib opencv_legacy2410d.lib opencv_flann2410d.lib

This is true for both release and debug builds. i built it, a x64 console app, under Visual Studio 2013. Using process explorer, I can see that I have the exact same command line (i.e. exact same app and args) and working directory for the exe launched via VS and manually from the command line. I can see it's using the same expected libraries (e.g. opencv_world310d for debug).

The opencv 3.1.0 was directly from the download (I didn't build it)

I'm running under Win10 x64.

Though it runs fine directly for the command line, in VS it blows up in the repeat function: First-chance exception at 0x00007FFFB5CF1F08 in HSV.exe: Microsoft C++ exception: cv::Exception at memory location 0x0000008AC80FB010.

That is not the the first opencv routine the program ran so...I'm baffled.

I copyied the repeat source code (out of copy.cpp) and made a repeata function out of it that I compiled and called with my app and that worked but then it blew up later on another opencv call.

If I hadn't had this running constantly for months under opencv 2.4.10 (Under VS2012)* or if it didn't run fine under both debug and release modes (using 3.1.0) outside VS 2013, I'd just chalk it up to a memory error elsewhere that just happen to finally make itself know but given this context I'm thinking it has something to do with the VS2013 environment but I don't know what to do about it.

• I took my errant VS2013 project and just changed it so that it linked (and loaded) the 2.4.10 (debug) libs/dlls and can run without any problems

So, it seems that just the fact that the project is linking and load 3.1.0 vs 2.4.10 libs/dlls is enough to make it crash but only in the VS2013 IDE(but the same executable and context run just fine from the command line)

I replaced the copyTo with a simple C loop (nothing generic)

unsigned char * pSource = Frame.data;
unsigned char * pDst = MovieFrames3DPlane.data;
int SourceStep = 1;
int DstStep = MovieFrames3DPlane.step.p[1];
for(int ip=0; ip < Frame.rows * Frame.cols; ip++) {
    *pDst = *pSource;
    pSource +=SourceStep;
    pDst +=DstStep;
}

and got a time just slightly better than matlab's (which is generic).

After thinking about it, I might do "your way", a vector of 2D Mats, because vent fast copying still means a few percent of my time budget and I'll have to do that twice. Unlike sum, I can't do a median (for each pixels across all planes) totally on the fly but I can constrain it via 256 bin histogram, for each pixel, vs sorting each pixel's vector.

I have several operations that I wan to perform in the 3rd dimension (e.g. median), but I also want to use the planes as images (i.e. the first 2 dimensions).

I find it bizarre that the concept of a 3d matrix seems to such an anathema to opencv. As a person who uses such all the time, albeit it Matlab, it seems quite unnatural limiting not to have it. Why would software that has multidimensional matrices fall apart after 2D requiring people to pick a pseudo 2d format that is likely fine for one use and bad for another (hence your question)? It is logical that any vector function be available across any dimension of any dimensional matrix. After all, it's just a question of the stride when accessing memory.

Anyway, sorry for the whine/rant. I will look at merge/split. Thanks