Posts filed under ‘Qt’

Extract pixel values from a bitmap in Qt

The first step in writing an image processing program is usually extracting the image data from a file container such as a bitmap or jpeg file. Using Qt, the QImage class makes this easy. The QImage can open/save directly to bmp, jpeg, and other common container formats. Once a file has been opened into an instance of a QImage, the RGB pixel values can be extracted into a luminance array for processing.

Here is a code example for extraction. In this case, an array of 32-bit value is used for storage even though only the lower byte has a value.
The RGB values are mapped to the luminance vector of the YUV color space.

December 24, 2012

Pitfalls of Qt Signals and Slots in embedded real-time systems

Qt Signals and slots can be very useful. Together with a model-view-controller framework, where the model emits signals to views and controllers, a very clean and logical system can unfold. However, one must be aware of a couple of pitfalls.

First, there is no control over the order in which slots are called from signals. This is true in both Queued connections and Direct connections. In complex systems, with many developers, there is a tendency for control to proliferate, and then multiple controllers are watching a signal. Then dependencies can develop between the outputs of these various controllers, sometimes with dire consequences.

The second problem is that once this disconnected architecture is in place, there is a tendency to write multiple signal observers without regard to other observers. So a developer may fire a signal, unaware that two other developers have slots watching those signals, and those slots may consume a lot of computational resources. For example one slot may drive a UI element to be created, while another slots starts a real-time process. So you may fire your signal expecting your slot to execute right away, and become bewildered when your slot code does not fire for 200 ms or longer.

There are no execution flow controls built-in to the Qt signal slot system, so the system architects must keep tabs on the signal flow. I find that its best to separate the model, the controllers, and the viewers into separate threads, then develop an asynchronous closed loop communication and synchronization scheme on all channels (with a managed memory scheme). When intentionally designing this type of communication between asynchronous elements, one is forced to wait for events to complete, and design with the expectation that execution times vary. Events that cannot be separated by an asynchronous gaps in time are collected together into a single thread context to gain determinism. This makes for a more robust design.

July 27, 2012

Deleting Qt Threads without crashing

I have an image processing application that needs to take advantage of multi-core processors, and as much parallelism efficiency as possible. So I wrote a worker thread class and a controlling class. The controlling class creates the worker threads, assigns them their jobs, then starts them. It then waits for all the workers to complete, deletes them, then moves on to the next phase of processing and repeats the cycle with new set of worker threads.

But my program would crash randomly. The entire processing job would take two hours on my 6 core machine, tens of thousands of threads would start and complete, and randomly it would all come crashing down. Sometimes a few minutes after start, sometimes an hour after.

This bug was frustrating. It turned out to be how and when I deleted the completed threads. I used the thread’s finished() signal to indicate that it was finished, and then deleted it. But it turns out this signal does not really mean finished. It means the code has returned from the run() call, but not all code is completed. Namely, a
mutex has not been released. So deleting the thread while that mutex was open, not a good thing. And deleteLater() did not make things better (did not investigate this).

So the fix is to use a new signal I created in the worker thread – completed() – that emits when the work is done, to tell my controller that the thread has done its job. Then I use the thread’s built in signal finshed() to call the thread deletion code:

This code checks the isFinished() method, which unlike the signal, does not return true until after the internal mutex is released. The call to wait() gives it chance to release that mutex before deletion. Now the program does not crash.

July 27, 2012


Archives