64bit OpenCV with Visual Studio 2013 - bizarre behaviour for cv::namedWindow() - c++

Currently trying to display a stream from an uEye camera using OpenCV. For this purpose I have Visual Studio 2013 and OpenCV 2.4.9 (64bit) at my disposal. Since things are not yet close to a release I'm using the debug libraries that are shipped with OpenCV (compiled with Visual Studio 2012).
I was trying to memcpy the image data that is returned by the camera to a cv::Mat object. After getting some weird error about a NULL pointer (string name of cvNamedWindow) I decide to check if I can actually run a very basic piece of code - read a PNG image and show it in a window. Well, it's not working... My mistake is probably still in the memcpy that I use but if you read below you will see that I have also tested a case where no camera is involved.
No matter if I give the absolute path of my image or simply point at the file where the EXE is I get an assertion failure from cv::imshow that either the height and/or width are not > 0. One other thing struck me here - the window name was all messed up - weird symbols, blank spaces etc. Nothing to do with what I have assigned as a name: "camOutput"
Further I decided to test things by manually creating a matrix of type CV_8U3 and filling it with black pixels. OpenCV showed the image yet the name of the window was again messed up. This time I was able to read the following, which seems to be some part of a command:
n in DOS mode.$
O_o I have never ever seen such weird behaviour especially when it comes to imshow, imread or namedWindow. Futher I can also not explain why imread returns an empty matrix no matter what I feed it. Tried PNG, JPEG and BMP - always the same crash.
EDIT: I have created an empty C++ project and transferred all my settings from the previous one. Now it's working. Even the memcpy for my uEye camera is fine and I can display the output in an OpenCV window. I have no idea what the problem was with my previous project. Will have to analyze further since the issue might reoccur. I will however leave this questioned opened because of that.

Related

Bad quality of images using GDI+ with PostScript driver

I'm developing a program to print images of different formats (BMP, JPEG, EMF, ...) on HDC using C++ and Windows GDI+. Using the MS Publisher Imagesetter driver I can generate a postscript file and through GhostScript functions I obtain the PDF file. If I try to print the following image:
I obtain the following bad quality result with those strange squares (not present on original image):
The part of my code that I used to print the image is:
SetMapMode(hdcPrint,MM_TEXT);
Gdiplus::Graphics graphics(hdcPrint);
graphics.SetPageUnit(Gdiplus::UnitMillimeter);
Gdiplus::Image* image = Gdiplus::Image::FromFile(srPicture->swPathImage);
graphics.DrawImage(image,x,y,w,h);
I tried to print the same image with many drivers and different kind of formats (different from PostScript: PDF, EMF, real printer) and the result is always acceptable (the squares are not present).
Furthermore, I tried to open the bad quality result with a pdf reader different from Adobe Acrobat Reader DC (Wondershare PDFelement and Chrome) and, even then, the result is acceptable.
I also noticed that if the image contains some different shapes (i.e. a big red line, like in the next image) the result is good too.
At this point, I have no idea if the problem is Adobe reader or my implementation.
Is there a differnt way to print different formats images with GDI+ (or pure GDI)?
The PostScript file generated is this.
Well... You haven't supplied either the PostScript or PDF files, which makes it really hard to comment.
Its not completely obvious to me at what point you are getting the image you show, is this what you see on the PDF file ? Is it something you are getting when printing the PDF file to a physical printer ? If its the lattter, how are you printing the PDF file to the printer ?
The JPEG you have supplied a link to is really small (6Kb), are you genuinely trying to use that JPEG file ?
My guess (and in the absence of any files, a guess is all it can be) that you are using an old version of Ghostscript. Old versions would decompress the JPEG image, then recompress the image using whatever filter produced the smallest result, usually JPEG again.
Because JPEG is a lossy format, every time you apply it to an image the quality decreases.
Newer versions of Ghostscript don't decompress the JPEG image data when going to the pdfwrite device, unless other optsions (eg Colour conversion, image downsampling etc) make it neccesary. The current version of Ghostscript is 9.27 and the release of 9.28 is imminent, I'd suggest you try one of those.
Another possibility would be that either the PostScript program has been created in such a way as to degenerate every image smaple to a rectangle, or you are using an extremely old version of Ghostscript where that technique was also used.
Note that none of these would, in my opinion, lead to exactly the result you've pasted here, but the version is certainly worth investigating. Posting the PostScript program file (ie the file you send to Ghostscript) would be more helpful, because it would allow me to at least narrow down where the problem has occured.
[EDIT]
The fault appears to be an intriguing bug in Acrobat.
The PostScript program uses a colour transfer function to invert the colour samples of the RGB JPEG image. (this is a frowned upon practice, its not what transfer functions are for, but its not uncommon). Ghostscript's pdfwrite device preserves the transfer function.
When rendered Ghostscript correctly produces the expected result, Acrobat, however, spectacularly does not, I have no idea what kind of mess they've made which leads to the result you get but its clearly wrong.
If I alter Ghostscript's pdfwrite production settings to Apply transfer functions instead of preserving them:
-c "<</TransferFunctionInfo /Apply>> setdistillerparams" -f PostScript.ps
then the resulting file views correctly in Acrobat. If I modify Adobe Acorbat's settings so that it uses Preserve instead of Apply for transfer functions (look in Settings->Edit Adobe PDF Settings, then the Color tab, and at 'when transfer functions are found', set the drop-down to Preserve instead of Apply) the resulting PDF file renders correctly in Ghostscript, and the same kind of incorrectly in Acrobat as the Ghostscript pdfwrite output file.
In short I'm afraid what you are seeing here is an Acrobat rendering bug, you can work around it by altering the Ghostscript transfer function settings as above but its really not a problem in Ghostscript.

OpenCV VideoCapture Partial Frame Corruption

I recently started using OpenCV for a project involving reading videos. I followed tutorials online for video's reading and the video seems to be read with no problems. However, when I display any frame from the video, the far right column appears to be corrupted. Here is the code I used for reading and displaying the first frame.
VideoCapture cap("6.avi");
Mat frame;
cap>>frame;
imshow("test",frame);
waitKey(0);
This resulted in a frame that looks good for the most part except the far right column. See here.
I am making no modifications to the video or frames before displaying it. Can anyone help figure out why this is happening?
Note: I'm running Ubuntu 14.04, OpenCV version 2.4.8
Full video can be found here.
Your code looks fine to me. Are you certain the frame is corrupted? Resize, maximize, minimize the "test" GUI window to see if the right edge is still corrupted. Sometimes while displaying really small images, I've seen the right edge of the GUI window display incorrectly even though the frame is correct. You could also try imwrite("test.png",frame) to see if the saved image is still corrupted.
If this doesn't help, it would seem like a codec problem. Ensure you have the latest version of opencv, ffmpeg.
If this still doesn't help, the video itself may be corrupted. You could try converting it into another format using ffmpeg

Can't open any files in Code::Blocks application during runtime

I am using Code::Blocks to make an OpenGL program in C++. The program compiles and runs, but the texture is never displayed. I just get an empty grey rectangle against a white background, when there should have been a picture in the grey rectangle.
I first noticed problems when trying to load the images for textures using the Simple OpenGL Image Library (SOIL). I did some digging around in the code of SOIL and found that the program was not opening any files at all. I tried changing image format, creating some random text files to test, and more, but it would not open any files of any type.
I think I may have the files in the wrong directory, but if so, where are they supposed to go? Right now, I have them saved in the same directory as the code.
Somewhere, you are giving paths to the files. These should be relative to the location of the executable. So examples could be this:
someFunction("file.jpg");
Here, the file.jpg should be somewhere like: <project_dir>/bin/Debug/
someFunction("../../file.jpg");
Now the correct location will be: <project_dir>/

Imshow() size restrictions

I have image 6750x6450 px and trying to display it with imshow() function from OpenCv.
When I display one image it's shown badly(some wired output), when I try to display two images get seqfault. Saving those images on hdd gives good results, images are saved, and they are correct, when I resize both they are also shown correctly. Has imshow() function some size restrictions?
code:
Mat bigImage1 = imread(...);
Mat bigImage2 = imread(...);
namedWindow("first",CV_WINDOW_FULLSCREEN);
namedWindow("second",CV_WINDOW_FULLSCREEN);
imshow("first",bigImage1);
imshow("second",bigImage2);
I'm working on desktop computer Windows 7 64bit
The images are probably larger than your current screen resolution. The problem seems to be that they are simply too big for OpenCV to handle them in a window.
To be certain, I would try your code on Mac or Linux since OpenCV is cross-platform and there are specific window management implementations for every OS.

How to create PNG images with Visual Studio C++ 2010?

IN: Visual Studio 2010 Ultimate, Windows 7
OUT: Some small ish PNG images that I will use as custom markers in Google Maps.
Language: C++ (or, if I really have to, C#)
Extra: I need to be able to plot the alpha channel (the transparency). I used PNGwriter library on a Linux machine and that didn't offer this feature.
Extra 2: The .exe will run on a server each time a new custom marker is needed. (Markers have different colors and shapes)
Edit: 1. I want to create a new image. 2. I need a library which I can't seem to find via Google yet.
Do you mean you want to convert from one file format to PNG using C++? Or that you want to render to an image and save the resulting image out as a PNG?
Either way, maybe you should take a look at FreeImage http://freeimage.sourceforge.net/features.html which is an open source image parsing/writing library that supports many formats, including PNG.
I created a kluge to do this. I used a common routine for getting the color (GetColor(red,green,blue,transparency)). I printed in two passes. The first pass would print to a 256 gray scale image. GetColor() would return the transparency as a shade of gray. The second pass would print to a 24-bit color image. GetColor would return the RGB color. After the two passes I merged the two bitmaps with the grayscale becoming the alpha channel for the PNG file.
C++ does not have any facilities built in for editing images. You'd need to find a library.
You could always use .NET.
I would suggest the built in System.Drawing namespace, which is available in both flavors - C++ and C#. Assuming you aren't against using Visual C++ Express, you can always take it from there.
Here's a link to the "official" documentation: System.Drawing Namespace
Within which is the System.Drawing.Graphics namespace, which is possibly what you would want to use.
AND here's a link to a nice little tutorial that will teach you how to import an image and draw on it (or possibly even draw it onto a bitmap): The Wonders of System.Drawing.Graphics
Boost.GIL can work with PNG.