OpenCV recently upgraded its display window, when it is used in Qt.
It looks very good, however I did not find any possibility for it to be embedded into an existing Qt GUI window. The only possibility seems to be the creation of a cvNamedWindow or cv::namedWindow, but it creates a free-floating independent window.
Is there any possibility to create that OpenCV window inside an existing GUI? All I could find on the OpenCV forums is an unanswered question, somewhat similar to my own.
There is a straight-forward possibility to show an OpenCV image in Qt, but it has two major problems:
it involves copying the image pixel by pixel, and it's quite slow. It has function calls for every pixel! (in my test application, if I create a video out of the images, and display it in a cvNamedWindow, it runs very smoothly even for multiple videos the same time, but if I go through the IplImage --> QImage --> QPixmap --> QLabel route, it has severe lag even for one single video)
I can't use those nice new controls of the cvNamedWindow with it.
First of all, the image conversion is not as inefficient as you think. The 'function calls' per pixel at least in my code (one of the answers to the question you referenced) are inlined by optimized compilation.
Second, the code in highgui/imshow does the same. You have to get from the matrix to an ARGB image either way. The conversion QImage -> QPixmap is essentially nothing else than moving the data from main memory to GPU memory. That's also the reason why you cannot access the QPixmap data directly and have to go through QImage.
Third, it is several times faster if you use a QGLWidget to draw the image, and I assume you have QT_OPENGL enabled in your OpenCV build. I use QPainter to draw the QPixmap within a QGLWidget, and speed is no issue. Here is example code:
http://sourceforge.net/p/gerbil/svn/19/tree/gerbil-gui/scaledview.h
http://sourceforge.net/p/gerbil/svn/19/tree/gerbil-gui/scaledview.cpp
Now to your original question: Your current option is to take the code from OpenCV, include into your project under a different namespace, and alter it to fit your needs. Apart from that you have no alternative right now. OpenCV's highgui uses its own event loop, connection to the X server etc. and it is nothing you can intercept.
My first guess is to want to say this: I'm sure that if you dig into the code for namedWindow, you will find that they use some sort of standard, albeit not oft-referenced, object for painting said window (that's in the openCV code). If you were ambitious enough, you could extend this class yourself, to interface directly to a frame or custom widget in Qt. There might even be a way to take the entire window and embed it, using a similar method of a Qt frame, or an extension of the (general) widget class. This is a very interesting question and relates rather directly to work I've been doing of late, so I'll continue to think about and research it and see if I can't come up with something else more helpful.
[EDIT] What specific new controls are you so interested in? It might be more efficient on the part of the programmer to extend a Qt control to emulate that, as opposed to my first suggestion.[/EDIT]
simply check out the opencv highgui implementation. as i recall it uses qt.
Related
I'm trying to graph some things in C++ and Koolplot seems like a very simple and suitable library to do so with. I'm stuck, however, on finding some documentation about it that allows me to fullscreen the application (or resize it like you can do so on lots of applications, chrome, word, discord...). As well as this, I can't find or see how i can allow the user to drag the graph around with the mouse as well as zooming into a point of a scatterplot or function. If anyone has any ideas about these things i'd appreciate it, thanks.
The short reply is: cannot do.
Koolplot uses for drawings of the charts a modernized version of the venerable BGI driver. It was invented once upon a time, when personal computers were still running on some DOS version. Those times the graphics were full screen, hence of fixed size. This particularity was kept in the modernized WinBGIm library.
Zooming or panning properly a chart present on the screen require access from the drawing/painting routines of Koolplot to the data to be shown. This is not the case. If you look once again in the source code, you will note that in the implementation efforts were made to keep separated data to be plot from the actual drawing on the screen.
In conclusion, to do what you want, you will have to modify WinBGIm such that it manages correctly a drawing surface of variable dimensions and modify koolplot such that data to be shown is owned by (or aggregated with) Plotstream class.
I am writing a video display software capable of displaying multiple video streams. For this I have a GridView holding VideoOutputs in QML connected to a QAbstractListModel derived class in c++ which provides instances of an object with a QAbstractVideoSurface Q_PROPERTY. It's working quite beautifully so far.
The video frames I am displaying come with metadata, however, containing data for axis aligned bounding boxes. I don't know beforehand how many boxes there are, the number could even change on a frame by frame basis, their position and size is also not set.
Ultimately, it should look something like this:
As I need to be able to display a few video streams at once, and preferably at 30+ fps, I need a fast method of drawing these boxes. Using QPainter on the QImage on which the QVideoFrame is based is rather slow so I was considering a few other approaches:
Using the QML object Rectangle in a Repeater with a c++ provided model (Was hoping to simply provide a QVariantList::fromVector() ): Could work, however I would need a lot of models which in turn I need to provide to QML with a model, and I would likely need to call begin/endResetModel every frame that the boxes change to cause QML to update - this is also very slow.
Using a Shader to draw the boxes: This is a rather difficult approach. I'm no stranger to shaders, but in Qt/Qml I don't know how to provide the shader with the information necessary.
Using OpenGL directly to draw the boxes: Again, I have no clue how to do this, but I think I could work it out if I googled.
My question: Which one, if any, of these approaches is the best? If none of these, which other approach could I use?
Thank you so much for taking the time to read my rather long question!
I have a program that needs to load a lot of QPixmaps. I split the loading of the pixmaps in several jobs using QtConcurrent::mappedReduced (I actually load a bunch of QGraphicPixmapItems). The loading function calls only the constructors of the QPixmaps/QGraphicItems, it does not attempt to perform any drawing, and it does not communicate with the rest of the world (at least through my code) until the loading is finished.
I get some random crashes during the initialization (say 1% of the times), and helgrind complains about unguarded accesses to QApplication from the QPixmap and from the main event loop, but it is known that Qt mutexes generally do not mix well with valgrind, so it might be a false positive.
As usual, the Qt documentation is quite unclear on whether QPixmap is reentrant or not, that is basically my question.
Well, you get crashes and you ask if it's OK? You already know the answer. It's not OK.
The only question I see here is whether it's a Qt bug. No, it's not.
If you want to load a lot of pixmaps, load them in into QImages, and then convert them into the backing store format. There isn't all that much to be gained these days from using a pixmap over an image. As long as the image has the same format as the widget's backing store (cast to QImage), you'll have same performance. The QPixmap distinction made sense when Qt still used native painting. On Windows and OS X, a pixmap is just a properly formatted QImage.
I have a QTimer for executing OpenCV code and changing an image in a QLabel every 20 milliseconds, but I want to run this OpenCV code more naturally and not depend on the timer.
Instead, I want to have one main thread that deals with user input and another thread that process images with OpenCV, what I can't find is a thread safe way to change the QLabel image (pixmap) in one thread from another thread, could someone describe this process, maybe give some code examples? I also want to know the pros and cons of using QThread, since it's plataform free, it sounds to be user level thread and not a system level which usually runs smoother.
You can only instantiate and work with QPixmap on the main (GUI) thread of your application (e.g. what is returned by QApplication::instance()->thread())
That's not to say you can't work with a QPainter and graphics objects on other threads. Most things work, with exceptions guided by constraints imposed by the OS.
Successive versions of Qt have managed to find ways to support things that previously didn't work. For instance:
Qt 4.0 added rendering QImages from separate threads
Qt 4.4 added the ability to render text into images
Qt 4.8 added the ability to use QPainter in a separate thread to render to a QGLWidget, QGLPixelBuffer and QGLFrameBufferObject
Where Qt 4.4 introduced QFontDatabase::supportsThreadedFontRendering to check to see if font rendering was supported outside the GUI thread, in Qt5 this is considered obsolete and always returns true
Note: you shouldn't hold your breath for the day that Qt adds support to work with QPixmap on non-GUI threads. The reason they exist is to engage the graphics layer directly; and finding a way to work around it just so you could use something named QPixmap wouldn't do any good, as at that point you'd just be using something equivalent to what already exists as QBitmap.
So all that has to do with the ability to instantiate graphics objects like QFont and QImage on another thread, and use them in QPainter calls to generate a graphical image. But that image can't be tied directly to an active part of the display...you'll always be drawing into some off-screen buffer. It will have to be safely passed back to the main thread...which is the gateway that all the direct-to-widget drawing and mouse events and such must pass through.
A well known example of how one might do this is Qt's Mandelbrot Sample; and I'd suggest getting started with that... making sure you understand it completely.
Note: For a different spin on technique, you might be interested to look at my Thinker-Qt re-imagining of that same sample.
I try to create something, where you can drop different things on it, like the Qt Creator (no, i don't want to create a new one, but i need the function of that).
You drag some elements and drop them anywhere in a tabPane.
My problem now is how to make a grid/raster in the background.
It should look similar to this:
I mean those dots in the background.
If I make them with two for loops, it will take hours and it's not efficient or anything else.
There has to be a more efficient solution and a lot easier one.
I'm programming in c++ with Qt as a Framework. Please give me some links or anything else I can use.
You can:
limit the repainting to region that really needs to be updated as explained in QWidget::paintEvent documentation,
fill a container of QPoint in your loops instead of drawing the points, and draw them all with QPainter::drawPoints after the loop,
cache the result in a QPixmap with transparency and reuse it if the window size didn't change (example from Qt Quaterly).
Of course, you should do some testing to see if you gain anything at all by doing any of these optimizations.