What exactly does this OpenCV program do? - visual-c++

I want to know exaclty what this program does:
#include <iostream>
#include <cv.h>
#include <cxcore.h>
#include <highgui.h>
using namespace std;
int main(int argc, char* argv[])
{
printf("Hello world\n");
IplImage *img = cvLoadImage("C:/Program Files/OpenCV/samples/c/lena.jpg");
// Create a window
cvNamedWindow( "result",
CV_WINDOW_AUTOSIZE // allow window to resize to fit image true size
);
cvShowImage( "result", img ); // Show image in window already created
// Wait for a keystroke. If a positive argument is given, it will wait for
// that number of milliseconds and then continue. If 0 is given, the
// program will wait indefinitely for a keypress.
cvWaitKey(0);
// Clean up (not really necessary, but good programming practice)
cvReleaseImage( &img );
cvDestroyWindow("result");
system("PAUSE");
return EXIT_SUCCESS;
}
The reason i'm asking is because I think that a picture is supposed to pop up when I run the program but instead for me, a grey box pops up.
Can someone please shed some light on this problem of mine? Thanks in advance.

It loads an image
Shows the image
then wait for anykey (0)
On anykey press
frees the memory used and return EXIT_SUCCESS
It should work correctly, probably that the path isn't right
try to copy your image in your working folder and execute from there while removing the full path in your image address
"lena.jpg"
Also another option would be to try backward slashes
"C:\\Program Files\\OpenCV\\samples\\c\\lena.jpg"
EDIT *
You should run the diagnosis tests included with openCV
they are located in the opencv\bin directory and should be able to check if your installation is correct or not

#include <stdio.h>
#include <cv.h>
#include <cxcore.h>
#include <highgui.h>
int main(int argc, char* argv[])
{
printf("Hello world\n");
IplImage *img = cvLoadImage("fruits.jpg",1);
// Create a window
cvNamedWindow( "result",
CV_WINDOW_AUTOSIZE // allow window to resize to fit image true size
);
cvShowImage( "result", img ); // Show image in window already created
// Wait for a keystroke. If a positive argument is given, it will wait for
// that number of milliseconds and then continue. If 0 is given, the
// program will wait indefinitely for a keypress.
cvWaitKey(0);
// Clean up (not really necessary, but good programming practice)
cvReleaseImage( &img );
cvDestroyWindow("result");
system("PAUSE");
return EXIT_SUCCESS;
}
Makefile (Make sure u have tab instead of 8 spaces!)
CFLAGS=-g -Wall
test = test
$(test): $(test).c
gcc -ggdb `pkg-config opencv --cflags --libs` -g -c -Wall $(test).c -o $(test).o
gcc -ggdb `pkg-config opencv --cflags --libs` -lpthread -lm $(test).o -o $(test)
clean:
#echo Removing generated files...
rm -f $(test).o $(test)
This program works for me! Best Regards, Virgoptrex! Tested on OpenCv 1.0 on Ubuntu 8.10!

Related

CEREAL failing to serialise - failed to read from input stream exception

I found a particular 100MB bin file (CarveObj_k5_rgbThreshold10_triangleCameraMatches.bin in minimal example), where cereal fails to load throwing exception "Failed to read 368 bytes from input stream! Read 288"
The respective 900MB XML file (CarveObj_k5_rgbThreshold10_triangleCameraMatches.xml in minimal example), built from the same data, loads normally.
The XML file was produced by
// {
// std::ofstream outFile(base + "_triangleCameraMatches.xml");
// cereal::XMLOutputArchive oarchive(outFile);
// oarchive(m_triangleCameraMatches);
// }
and the binary version was produced by
// {
// std::ofstream outFile(base + "_triangleCameraMatches.bin");
// cereal::BinaryOutputArchive oarchive(outFile);
// oarchive(m_triangleCameraMatches);
// }
Minimal example: https://www.dropbox.com/sh/fu9e8km0mwbhxvu/AAAfrbqn_9Tnokj4BVXB8miea?dl=0
Version of Cereal used: 1.3.0
MSVS 2017
Windows 10
Is this a bug? Am I missing something obvious?
Created a bug report in the meanwhile: https://github.com/USCiLab/cereal/issues/607
In this particular instance, the "failed to read from input stream exception" thrown from line 105 of binary.hpp arises because the ios::binary flag is missing from the ifstream constructor call. (This is needed, otherwise ifstream will attempt to interpret some of the file contents as carriage return and linefeed characters. See this question for more information.)
So the few lines of code in your minimal example that read from the .bin file should look like this:
vector<vector<float>> testInBinary;
{
std::ifstream is("CarveObj_k5_rgbThreshold10_triangleCameraMatches.bin", ios::binary);
cereal::BinaryInputArchive iarchive(is);
iarchive(testInBinary);
}
However, even after this is fixed there does also seem to be another problem with the data in that particular .bin file, as when I try to read it I get a different exception thrown, seemingly arising from an incorrectly encoded size value. I don't know if this is an artefact of copying to/from Dropbox though.
There doesn't seem to be a fundamental 100MB limit on Cereal binary files. The following minimal example creates a binary file of around 256MB and reads it back fine:
#include <iostream>
#include <fstream>
#include <vector>
#include <cereal/types/vector.hpp>
#include <cereal/types/memory.hpp>
#include <cereal/archives/xml.hpp>
#include <cereal/archives/binary.hpp>
using namespace std;
int main(int argc, char* argv[])
{
vector<vector<double>> test;
test.resize(32768, vector<double>(1024, -1.2345));
{
std::ofstream outFile("test.bin");
cereal::BinaryOutputArchive oarchive(outFile, ios::binary);
oarchive(test);
}
vector<vector<double>> testInBinary;
{
std::ifstream is("test.bin", ios::binary);
cereal::BinaryInputArchive iarchive(is);
iarchive(testInBinary);
}
return 0;
}
It might be worth noting that in your example code on Dropbox, you're also missing the ios::binary flag on the ofstream constructor when you're writing the .bin file:
/// Produced by:
// {
// std::ofstream outFile(base + "_triangleCameraMatches.bin");
// cereal::BinaryOutputArchive oarchive(outFile);
// oarchive(m_triangleCameraMatches);
// }
It might be worth trying with the flag set. Hope some of this helps.

Wemos - oled sparkfun print text does not display

I'm using a led matrix shield (http://www.wemos.cc/Products/oled_shield.html) with a wemos. I'm using Arduino IDE.
The exemples work perfectly (https://github.com/wemos/D1_mini_Examples/tree/master/04.Shields/OLED_Shield/Use_SparkFun_Library)
But when I try to print text, the screen remains empty. Here is my code
#include <Wire.h>
#include <SFE_MicroOLED.h> // Include the SFE_MicroOLED library
#define PIN_RESET 255
#define DC_JUMPER 0
MicroOLED oled(PIN_RESET, DC_JUMPER);
void setup()
{
oled.begin();
oled.clear(ALL);
oled.clear(PAGE);
oled.display();
oled.setFontType(0);
oled.setCursor(0, 0);
oled.print("Hello, world");
oled.display();
}
void loop()
{
}
Any idea ?
I solved the issue. I modified SFE_MicroOLED lib.
The fonts are loaded in the program memory (via PROGMEM directive). This makes the code fail on wemos.
I remove PROGMEM directive on a fork of this lib (https://github.com/landru29/SparkFun_Micro_OLED_Arduino_Library)
I just check if the arch is ARDUINO_ESP8266_NODEMCU
https://github.com/landru29/SparkFun_Micro_OLED_Arduino_Library/blob/master/src/util/7segment.h#L37 (idem for all other font files in the same folder)

Linux alternative to _NSGetExecutablePath?

Is it possible to side-step _NSGetExecutablePath on Ubuntu Linux in place of a non-Apple specific approach?
I am trying to compile the following code on Ubuntu: https://github.com/Bohdan-Khomtchouk/HeatmapGenerator/blob/master/HeatmapGenerator2_Macintosh_OSX.cxx
As per this prior question that I asked: fatal error: mach-o/dyld.h: No such file or directory, I decided to comment out line 52 and am wondering if there is a general cross-platform (non-Apple specific) way that I can rewrite the code block of line 567 (the _NSGetExecutablePath block) in a manner that is non-Apple specific.
Alen Stojanov's answer to Programmatically retrieving the absolute path of an OS X command-line app and also How do you determine the full path of the currently running executable in go? gave me some ideas on where to start but I want to make certain that I am on the right track here before I go about doing this.
Is there a way to modify _NSGetExecutablePath to be compatible with Ubuntu Linux?
Currently, I am experiencing the following compiler error:
HeatmapGenerator_Macintosh_OSX.cxx:568:13: error: use of undeclared identifier
'_NSGetExecutablePath'
if (_NSGetExecutablePath(path, &size) == 0)
Basic idea how to do it in a way that should be portable across POSIX systems:
#define _XOPEN_SOURCE 500
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
static char *path;
const char *appPath(void)
{
return path;
}
static void cleanup()
{
free(path);
}
int main(int argc, char **argv)
{
path = realpath(argv[0], 0);
if (!path)
{
perror("realpath");
return 1;
}
atexit(&cleanup);
printf("App path: %s\n", appPath());
return 0;
}
You can define an own module for it, just pass it argv[0] and export the appPath() function from a header.
edit: replaced exported variable by accessor method

Qt5 and GLEW MX => glewInit fails

We are migrating our project from Qt 4.8 to 5.4. We use multiple contexts in multiple thread. We use GLEW MX for this purpose (We make the context we desire current then call glewInit() on a local instance of GLEWContextStruct).
I'm trying to change QGLWidget and QGLContext to QOpenGLWidget and QOpenGLContext but I ended up not being able to initialize glew anymore.
GLEW doesn't return an error but glGetError() does.
I did install Qt 5.4 64 with OpenGL version.
Here is the code reduced to a minimum :
#include <QtWidgets/QApplication>
#define GLEW_MX
#define GLEW_STATIC
#include <GL/glew.h>
#include <qopenglcontext.h>
#include <qwindow.h>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
bool errQt;
int errGlew;
GLenum errorGL;
QSurfaceFormat requestedFormat;
requestedFormat.setVersion(3, 3);
requestedFormat.setProfile(QSurfaceFormat::OpenGLContextProfile::CoreProfile);
//Creates the QGLWidget using the current context:
QWindow window;
window.setSurfaceType(QSurface::OpenGLSurface);
window.setFormat(requestedFormat);
window.create();
//Create context
QOpenGLContext context;
context.setFormat(requestedFormat);
errQt = context.create(); //true
//Bind context
context.makeCurrent(&window);
//Glew context creation
GLEWContext* pCtx = new GLEWContext; //All forwards undefined
//Release context
context.doneCurrent();
return 1;
}
Any suggestion ? Is GLEW alright with Qt5.4 ?
EDIT 1 :
It appears the problem is not Qt related. The GLEWContext created doesn't have any function forward defined (all function pointers are undefined). The code has been updated to help the reviewer not lose focus.
I use glewInit() with Qt 5.4 in my project, but I'm using QWindow as my base class, not QOpenGLWidget.
In my ctor I do this:
QRiftWindow::QRiftWindow() {
setSurfaceType(QSurface::OpenGLSurface);
QSurfaceFormat format;
format.setDepthBufferSize(16);
format.setStencilBufferSize(8);
format.setVersion(4, 3);
format.setProfile(QSurfaceFormat::OpenGLContextProfile::CoreProfile);
setFormat(format);
m_context = new QOpenGLContext;
m_context->setFormat(format);
m_context->create();
...
I execute my OpenGL work on a separate thread. Once the thread has started I call an setup method on my class
m_context->makeCurrent(this);
glewExperimental = true;
glewInit();
glGetError();
I've previously done this exact same setup with OpenGL 3.3 and had no issues.
You should actually get a warning about that:
#warning qopenglfunctions.h is not compatible with GLEW, GLEW defines will be undefined
#warning To use GLEW with Qt, do not include or after glew.h
Your "qopenglcontext.h" includes . To answer your question, you can use Qt + GLEW, but u can't easily mix up Qt-opengl with GLEW.

Create a shared lib using another shared lib

I have a shared library "libwiston.so". I am using this to create another shared library called "libAnimation.so", which will be used by another project. Now, the second library "libAnimation.so" can't be used in test code correctly. So I doubt that the creation of the second lib "libAnimation.so" is right. The gcc command to create this lib is
g++ -g -shared -Wl,-soname,libwiston.so -o libAnimation.so $(objs) -lc".
Has someone come across this problem?
That looks like a weird link line - you are creating libAnimation.so, but its internal DT_SONAME name is libwiston.so.
I don't think that what you wanted to do. Don't you want to link libAnimation.so against libwiston.so (-lwiston)?
g++ -g -shared -o libAnimation.so $(objs) -lc -lwiston
I think it would be easier to wrap your build in automake/autoconf and rely on libtool to get the shared library creation correct.
I'll do a humble review on the process of creating shared libraries.
Let's begin by creating libwiston.so. First we implement the function we would like to export and then define it on a header so other programs knows how to call it.
/* file libwiston.cpp
* Implementation of hello_wiston(), called by libAnimation.so
*/
#include "libwiston.h"
#include <iostream>
int hello_wiston(std::string& msg)
{
std::cout << msg << std::endl;
return 0;
}
and:
/* file libwiston.h
* Exports hello_wiston() as a C symbol.
*/
#include <string>
extern "C" {
int hello_wiston(std::string& msg);
};
This code can be compiled with: g++ libwiston.cpp -o libwiston.so -shared
Now we implement the second shared library, named libAnimation.so that calls the function exported by the first library.
/* file libAnimation.cpp
* Implementation of call_wiston().
* This function is a simple wrapper around hello_wiston().
*/
#include "libAnimation.h"
#include "libwiston.h"
#include <iostream>
int call_wiston(std::string& param)
{
hello_wiston(param);
return 0;
}
and header:
/* file libAnimation.h
* Exports call_wiston() as a C symbol.
*/
#include <string>
extern "C" {
int call_wiston(std::string& param);
};
Compile it with: g++ libAnimation.cpp -o libAnimation.so -shared -L. -lwiston
Finally, we create a small application to test libAnimation.
/* file demo.cpp
* Implementation of the test application.
*/
#include "libAnimation.h"
int main()
{
std::string msg = "hello stackoverflow!";
call_wiston(msg);
}
And compile it with: g++ demo.cpp -o demo -L. -lAnimation
There's an interesting tool named nm that you can use to list the symbols exported by your shared library. Using these examples, you could execute the following commands to check for the symbols:
nm libAnimation.so | grep call_wiston
outputs:
00000634 t _GLOBAL__I_call_wiston
000005dc T call_wiston
and also:
nm libwiston.so | grep hello_wiston
outputs:
0000076c t _GLOBAL__I_hello_wiston
000006fc T hello_wiston

Resources