I'm wondering whether there is OpenCV documentation on VideoCapture lists compatible sensor configurations e.g. Resolution < 640x480 || FPS < 1e100. Basically I am wondering whether the class is compatible with large resolutions such as 1960x1080 or even 2304x1536, and whether there are run-time implications of this even if the height/width fields can be set.
OpenCV provides a simple cross-platform video input API. It does not attempt to provide a comprehensive feature list, and even (some of) the properties it does provide, do not alwyas work with all hardware and platforms.
The whole highgui module is mostly aim at rapid prototyping and not for bulletproof video I/O. If your platform provides more advanced SDKs for image capture and configuration, you can use those SDKs and simply pass the resulting image buffers to be wrapped with cv::Mat().
Related
I am writing C++ class for managing multiple cameras and reading frames from them. Let's say it is wrapper for OpenCV. Currently I am finding cameras by trying to create devices from 0-10 range and If there is output I know that I've found working camera. I can always save internal IDs of those cameras to distinguish them but what If another camera is plugged in? It may break the order of IDs. So is there any way to distinguish OpenCV cameras for example by getting their hardware IDs?
I know this doesn't help you much, but the short answer is "No, OpenCV doesn't currently provide that capability."
According to the doc, any hardware ids are not properties you can retrieve using the get method or any other.
Having said that, if you're very intent on using OpenCV, I would still test the behavior of OpenCV 2.4.10 on various platforms and using various middleware and see how it behaves. If you get a consistent behavior, then you can run with it, but be somewhat ready for it to break in the future. What would work for you is that OpenCV is using various middleware in the backend, such as V4L, Qt, etc., and these are well-maintained and more-or-less consistent.
In retrospect, I would stay away from OpenCV's video interface altogether right now for commercial software, unless you're okay with the situation I described. Beware that OpenCV 3.0 videoio library is unstable at this point and has open bug reports.
I am using OpenCV to show image on the projector. But it seems the cv::imshow is not fast enough or maybe the data transfer is slow from my CPU to GPU then to projector, so I wonder if there is a faster way to display than OpenCV?
I considered OpenGL, since OpenGL directly uses GPU, the command may be faster than from CPU which is used by OpenCV. Correct me if I am wrong.
OpenCV already supports OpenGL for image output by itself. No need to write this yourself!
See the documentation:
http://docs.opencv.org/modules/highgui/doc/user_interface.html#imshow
http://docs.opencv.org/modules/highgui/doc/user_interface.html#namedwindow
Create the window first with namedWindow, where you can pass the WINDOW_OPENGL flag.
Then you can even use OpenGL buffers or GPU matrices as input to imshow (the data never leaves the GPU). But it will also use OpenGL to show regular matrix data.
Please note:
To enable OpenGL support, configure OpenCV using CMake with
WITH_OPENGL=ON . Currently OpenGL is supported only with WIN32, GTK
and Qt backends on Windows and Linux (MacOS and Android are not
supported). For GTK backend gtkglext-1.0 library is required.
Note that this is OpenCV 2.4.8 and this functionality has changed quite recently. I know there was OpenGL support in earlier versions in conjunction with the Qt backend, but I don't remember when it was introduced.
About the performance: It is a quite popular optimization in the CV community to output images using OpenGL, especially when outputting video sequences.
OpenGL is optimised for rendering images, so it's likely faster. It really depends if the OpenCV implementation uses any GPU acceleration AND if the bottleneck is on rendering side of things.
Have you tried GPU accelerated OpenCV? - http://opencv.org/platforms/cuda.html
How big is the image you are displaying? How long does it take to display the image using cv::imshow now?
I know it's an old question, but I happened to have exactly the same problem. And from my observations I've concluded that the root of the problem is the projector's own latency, especially if one is using an older model.
How have I concluded it?
I displayed the same video sequence with cv::imshow() on the laptop monitor and on the projector. Then I waved my hand. It was obvious, that projector introduces significant latency.
To double-check, I've opended a webcam video, waved my hand in front of it and observed the difference on the monitor and on the projector. Webcam does no processing, no opencv operations, so in my understanding the only thing that would explain the latency would be the projector itself.
I just can't find them anywhere. The most important part for me is the hardware acceleration, and I have no idea if there is a performance or openGL version compatibility requirement that the video card has to follow.
The minimum system requirements will depend alot more on the application that you are writing than what SDL2 does.
If you just create a standard window and render SDL will use what it can find and what it thinks is best either OpenGL, OpenGL ES, Direct3D or use the old style software rendering for machines that can't do any of the other. So if a computer can support an OS that SDL runs on then you will almost always (I just said almost since there can possible be exceptions) be able to run these type of apps (Video card not a requirement, but having one will greatly increase programs drawing speed).
You can also be creating a OpenGL application directly and then it depends on what type of context you are making what the video card has to support.
You can find most of the information here: http://wiki.libsdl.org/moin.fcg/MigrationGuide
under the Video section. It's actually how to port from 1.2 to 2.0 , but it explains the new Video Pipeline pretty well.
Hope thats what you were looking for.
I'm currently using MFC/GDI and Stingray to display bitmaps in my application and am looking for a better solution. Specifically;
Faster drawing speed - My current solution is slow, based on StretchDIBits
Better rendering quality - StretchDIBits rendering quality is awful when scaling a bitmap
Support for rotated bitmaps
Support for loading / saving in all popular formats
Support for large bitmaps - I'm regularly using aerial photographs that are ~64mb as 12,000x12,000 jpegs. GeoTIFF support would also be useful
Compatible with MFC document/view, including printing (e.g. must be able render to a CDC)
Access to source code is good but not necessary
Easy to use / port existing GDI code
While free is always nice, I don't mind spending a reasonable amount on a decent library, though no run time royalty costs. Googling suggests the following;
CImg
Graphics Magick
Lead Tools imaging SDK
Anyone got experience of these or can recommend an good alternative?
GDI+ is available on any Windows machine since early XP. It has codecs for all popular image formats, JPEG is included. Very nice filters for high-quality image rescaling. Unrestricted image rotation. Draws to a CDC through the Graphics class. Source code for the C++ wrappers are available in the SDK gdiplusXxx.h header files. Speed is likely to be equivalent however, rendering is software based to ensure compatibility.
You can #include <gdiplus.h> and use the C++ wrappers directly. The SDK docs are here. The CImage class is available in MFC, it doesn't expose all capabilities however.
I think it's unlikely you'll find something that performs faster than GDI on windows since it has kernel-level support which is something open source solutions will not have.
You might want to also look into OpenGL or Direct2D/Direct3D since these too have direct access to the frame buffer. With 3D APIs, texture size would probably be an issue since most standards limit to something like 4096x4096.
I have used CxImage in the past which is one to add to your evaluation list.
What are some cross platform and high performance image libraries for image processing (resizing and finding the color/hue histograms). No gui needed. This is for C/C++.
So far I have looked in to
OpenCV
GIL as part of Boost
DevIL
CImg
My questions
How's the performance of the ones I have listed above
What are some other libraries
Your input much appreciated.
OpenCV has quite good performance. It should be sufficient for most cases.
To improve performance, you can also use OpenCV together with Intel IPP, which is however a non-free commercial product. If OpenCV detects that IPP is installed it will use it where possible.
As a third option you can use IPP directly. IPP was designed with high performance (on Intel architectures) as a goal. It is optimized to use the intel SIMD instructions.
imagemagick is quite popular.
I don't think I've seen anything better in features and performance than HALCON from MVTec. It provides all sort computer vision and image processing algorithms out-of-the-box and plenty of real life examples. The library uses multithreading as much as algorithms could possibly allow and GPU when available. It's very cross-platform and provides a fantastic IDE that will allow you to export your prototype code (algorithm) to many languages including C, C++, C# and more.
One of the best features of this library is how they treat region objects. It is just incredibly smart and efficient both for storage and mask processing. Unfortunately OpenCV has a lot to learn from it.
The main problem with this package is the price (stupidly high) but if you are working on a project where you don't need to deploy runtime licenses (e.g. SaaS) then this is the way to go, look no further if you require serious image processing and computer vision.
Don't forget to look at CxImage - I've used it professionally in globally deployed graphics intensive mobile phone applications, where it performed perfectly and it's so full of features. Do check it out!
I help maintain libvips, a free, cross-platform C/C++ scientific image-processing library. It is fast and works well on very large images.
I did a very simple benchmark: load a 10,000 x 10,000 pixel RGB tif, crop 100 pixels off every edge, shrink 10%, sharpen, and save again. On this trivial test at least, vips is more than twice as fast as anything else I've tried.
The C++ API is documented here. For example:
#include <vips/vips8>
using namespace vips;
int
main( int argc, char **argv )
{
// startup, load plugins, init support libraries, etc.
if (VIPS_INIT(argv[0]))
vips_error_exit(NULL);
// the "sequential" access hint means we plan to only read this image
// top-to-bottom (eg. no 90 degree rotates) ... this means libvips can
// stream the image and run decode and processing in
// parallel on separate threads
VImage image = VImage::new_from_file(argv[1],
VImage::option()->set("access", "sequential"));
// shrink to 20% and find the histogram
VImage hist = image.resize(0.2).hist_find();
hist.write_to_file(argv[2]);
return 0;
}
You can run this program with any input and output image format, for example:
$ g++ -g -Wall resize.cpp `pkg-config vips-cpp --cflags --libs`
$ ./a.out ~/pics/wtc.jpg x.csv
And it'll read the JPG input and write the histogram to the CSV file.
There is a simple and free open source cross-platform image processing library Simd. As follows from its description:
It provides many useful high performance algorithms for image processing such as: pixel format conversion, image scaling and filtration, extraction of statistic information from images, motion detection.
The algorithms are optimized with using of different SIMD CPU extensions: SSE, SSE2, SSSE3, SSE4.1, SSE4.2, AVX, AVX2 and AVX-512 for x86/x64, VMX(Altivec) and VSX(Power7) for PowerPC, NEON for ARM.
You might want to look at IM. It builds on several platforms, and has support for (modular) image file formats, a variety of image representations, and a wide array of transformations and operators. A GUI tool, IMLab, for demonstrating image processing operators based on the IM library is also available.
There are also VTK and ITK, with a huge amount of manifold image processing algorithms.
There are also:
Framewave based on AMD Performance Library which provides signal and image processing features
GraphicsMagick multi-threaded derivative from ImageMagick
ExactImage is a fast C++ image processing library. Unlike many other library
frameworks it allows operation in several color spaces and bit depths
natively, resulting in low memory and computational requirements.
We used Accusoft for quite a while, but for very specific reasons we switched to LeadTools, which exists for windows only.
Accusoft has a very clear and much more well defined interface than leadtools. Both libraries are very robust and both claim to read more or less all existing file types. Both also have quite responsive support.