Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Talk:Multi-Threaded Image Processing using Qt Camera

From Wiki
Jump to: navigation, search


Hamishwillee - Very nice

I'm a big fan of articles that show how to improve performance and keep the UI responsive. I really like that you've included references to the code you've used (like the camera demo example) and little things like explaining which Symbian capabilities are needed for what part of the code (camera, files etc). Also good you've linked to API reference when you first mention classes.


  1. Does this work on MeeGo too? If so, please add MeeGo category.
  2. Explanation of "Receiving viewfinder frames from the camera" useful. Worth linking to MeeGo Camera VideoSurface manipulation for a more detailed explanation of this part?
  3. QML is an acronym, should always be capitalised unless in a class name.
  4. Where you say "When a full-resolution picture arrives it is copied to the worker thread." its worth adding a link down to the following section (ie "This is described below"). When I read this section first time I didn't know you had provided the information below so it was a bit disappointing to think you'd glossed over it.
  5. Discussion about hardware acceleration is interesting but inconclusive. I get the impression there isn't any point in doing it, but in fact there probably are cases - is there an example of where exploring OpenGl or something else does become reasonable.
  6. As a rule I use Template:Icode for marking up in-line comments rather than italic.
  7. As the main point of this article is the worker thread, and its benefits, you should link to reference documentation on worker threads in Qt doc. Also, would be great to know what sort of impact NOT using worker thread would have had in this particular case - if you can calculate it. Idea is to give users some indication of the point at which you have to consider using the information.
This article is excellent. Thank you.

hamishwillee 10:33, 16 May 2012 (EEST) -

Hi, Thanks for your constructive feedback. I have included your suggestions in the article except the impact of the worker thread. It's kind of hard to give numbers for this because the worker thread will indeed decrease processing performance a bit. But the point here is to keep the user interface responsive to user input. Regards,

Harald 21:41, 18 May 2012 (EEST)

Hamishwillee - Thank you

Hi Harald

Thanks for the update. I'll review it properly in the coming week (I hope!).

As you say a major benefit is in UI responsiveness - if the processor is going flat out on one task it won't be able to do double the work. However it is important to remember that the processor isn't always going flat out, bottlenecks can be elsewhere, and this allows you to capitalise on that. As an example, prior to the competition this article QHdrCamera component for High Dynamic Range Imaging did everything sequentially in the main thread - taking the three images and then editing them to create the final HDR image. galazzo has since made this multi threaded, with significant gains. Now it can start processing the images when they are taken (a time when most of the work is being done by camera hardware, not the processor. The result is that editing starts 4 seconds earlier and completes not long after the last photo is taken. So, both perceived and actual improvement. I'm sure you know all that :-)

I did get some feedback from another reader on this article "Useful, but it looks more like a part of existing application, and not so reusable as an article/tutorial". I do see their point but this would a fair bit of restructuring work, so this is completely up to you. It is still a very good article.



hamishwillee 05:05, 22 May 2012 (EEST) -


I totally agree that multi-theading is a winner when multiple tasks can be run in parallel. But the main intention of this article is to use multi-threading for live data which you cannot just put into a working queue. I have added the QHdrCamera idea as a comment to the article, although it is a bit off-topic.

I have written this article and the demo-app from scratch based on my past experiences and also with several questions from users in various online discussion boards in mind. I think it's a very important topic because multi-threading is often avoided because it seems too complex. This article gives all you need for beginning with it especially for live data such as image processing. I have included many parts of the project code (e.g. introduction) into the article because they show classical problems with image processing which are then posted in discussion forums (e.g. app crashes, why? --> stack size too small, missing capabilities, etc.). These parts are often missed when looking into the project's source code because (what everyone does) only the algorithmic parts are looked at :).

Regards, 08:15, 22 May 2012 (EEST)

Hamishwillee - All true

Hi Harald

Thanks for your explanation and for your updates. I completely agree with your statements and the value of the tips provided. I don't think that these preclude a more "tutorial style" - but its your call. Personally I think its a very good and useful article.

I would still suggest links to the Qt documentation on multithreading.



hamishwillee 08:36, 25 May 2012 (EEST)


Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.