Live camera image in QGraphicsVIew
-
I hope it does not sound disrespectful but it does not help a lot.
I was in fact looking for guidelines from people who may have already been working on the same kind of stuff.
"Use FIFO and drop images", ok why not but you know what they say "devil is in the details", how do you limit the size of your FIFO, how do you decide to drop images, etc. -
The first thing to do is to identify the bottlenecks you have (i.e the conversion from QImage to QPixmap) using either a QTime for basic measurement or a more professional tool if you have one.
Then you have two model applicable to your problem:
- push
- pull
Since you are considering the pull model (with the consumer/producer paradigm) you can use this design:
- A ring buffer with pre-allocated buffers where you copy the image data and your other thread gets them as fast as it can.
- A semaphore to make your consumer waits when the ring buffer is empty.
The ring buffer allows you to easily know when your system cannot sustain the throughput.
It's then up to you to decide whether you overwrite the old data, stop the stream, emit a warning etc... That is essentially application dependentIf you need to display things faster, then you probably have to go the OpenGL way (there is a QQ article about threaded rendering)
One last point of interest might be to get the data as fast as possible to the graphic card using i.e. CUDA, OpenCL etc...
I would need more information about what your application does to give better advices.
-
Thanks a lot for your answer.
Bottleneck depends on camera/system so I should be able to handle slow framerates (images are consumed faster that produced) and high framerate/slow computer (images are produced faster than consumed)cuda/hardware acceleration is not an option here unfortunately
when the consumer thread ask for an image, how would you then pass it to the mainthread for display? and lock it until it is actually drawn?
-
For the slow frame rates your consumer will wait on the producer (either QWaitCondition or QSemaphore) so that should no really be a problem, the screen update will happen just after a new image has arrived.
For the other case, you can reduce the size of the image shown, or the image produced (if possible to configure the camera) or slow down the frame rate either configuring the camera or the producer (i.e dropping one frame out of 5 or whatever it would take)
Copy the data from the ring buffer (i.e in a QByteArray) and you don't need to lock it any further (besides while copying of course).
-
Thanks (again) for the details.
My current implementation has a ring buffer however there's no consumer, just a producer that emits signal when an image is ready.
The flaw here is that I don't lock anything when the main thread handles the signal (ie. copy the data)Now it's time to code. Thank you SGaist!
-
What's the signal signature and how does you application react to it ?
-
The signal passes the buffer "pointer (do not laugh!), width and height of the image":http://qt-project.org/forums/viewthread/29786/#134745.
I know I should be ashamed to say that, but I wrote that a while ago and never touched it since then. -
Just to be sure:
You get an image
Add it to your ring buffer
emit a signal with the address of the data in the ring buffer
Did I understand you right ?
-
It's supposed to be a bit more secure.
I have a ping/pong buffer plus a third "locked" buffer that should prevent concurrent access, but that is in part broken and that's why I ended up here asking for guidelines :) -
Ok ok,
Then with the ring buffer you can have another thread read the data in a QByteArray or directly in a QImage and send that to your gui thread. A bit like the mandelbrot example
-
I'll have a look at that example. Thanks again
