Discussion :

[mchk0123]

Bonjour à tous,

Voilà j'essaye d'utiliser Qt pour faire une simple form affichant une image, puis lancer un traitement sur l'image assez long pendant lequel je veux afficher les résultats en modifiant les pixels un à un à chaque fois que le traitement de l'image l'a calculé.

Cela me permet de "debugger" mon algorithme. Le côté "temps réel" (bien que ce n'en soit pas vraiment au sens strict) est trés important car je veux voir la dynamique du calcul.

Je m'y perd un peu entre les différents moyen d'afficher une image (bitmap dans un label, QtPainter, BlitMapping, double buffering, ...) quel est le meilleur moyen pour éviter le flicking étant donné mes besoins ?

Merci.

[IrmatDen]

Salut,

Tu n'auras pas à souffrir de flicking; Qt4+ (quoique tu n'as pas spécifié ta version, c'est laquelle?) offre un mécanisme de double buffering par défaut sur la majorité des plateformes.

Je me sers de QLabel+QPixmap pour les images fixes, ce qui n'est pas ton cas donc
QPixmap est optimisé pour l'affichage, alors que QImage est optimisé pour le traitement. Quoiqu'il arrive, tu devras créer donc 2 QImage: le courant et le support de travail, ensuite tu en fais un QPixmap pour affichage.
Selon la taille et les fonctions à supporter, je te conseillerais de créer un widget personnalisé dérivant de QAbstractScrollArea (suggestion seulement )

[mchk0123]

Merci pour la réponse.

Je vais suivre tes conseils. Pour le QImage, comment je peux faire pour modifier un pixel à la fois ? Je passe par un QPainter (ce le seul objet Qt que j'ai trouvé qui à une méthode DrawPoint) ? Ou est-ce que je peux avoir directement accès aux pixels par un pointeur sur une zone mémoire ?

[IrmatDen]

QImage::pixel() et QImage::setPixel(). Tu peux éviter le QPainter pour ces opérations

Tu as aussi QImage::bits() qui correspondra probablement plus à ce que tu cherches?

[mchk0123]

setPixel() me va trés bien. Je vais m'orienter vers cette solution simple.

Un début de piste pour l'enchainement des refresh entre :

QImage (buffer) -> QImage (courant) -> QPixmap (conversion) -> QLabel ?

C'est à dire qu'elles méthodes je dois choisir étant donné mon pb. (il y en à tellement) ?

Plus ça va, plus je me demande si c'est pas un peu lourd comme châine de traitement, alors que je ne change qu'un pixel à la fois ! (On ne peut pas dessiner directement sur le Canvas, pour un pixel ?)

[IrmatDen]

(On ne peut pas dessiner directement sur le Canvas, pour un pixel ?)

Euh, là, t'en as pas assez dit alors
Si tu parles de QCanvas, tu es sous Qt3, ça peut changer des choses (comme le problème du double buffering précisé dans le 1er post). De plus si tu utilises un QCanvas, tu n'as pas besoin d'un QLabel, mais soit d'une classe dérivant de QCanvasItem.

Alors, quelle est ta situation exacte?

[mchk0123]

Je suis bien sous Qt4.2.3 mingw mais ce que je demande c'est si passer par 4 objets différents (2x QImage, QPixmap, QLabel) avec une recopie de l'image entre chaque ça ne risque pas d'être lent : car je veux vraiment voir les pixels s'afficher les 1 aprés les autres.

Donc c'est pour ça que j'avais aussi pensé à QCanvas (plus rapide ?) mais que j'avais laisser tomber car je n'arrivais déjà pas à afficher les pixels (l'image restait toujours noire).

[IrmatDen]

Merci pour ces précisions.

Je suis bien sous Qt4.2.3 mingw mais ce que je demande c'est si passer par 4 objets différents (2x QImage, QPixmap, QLabel) avec une recopie de l'image entre chaque ça ne risque pas d'être lent : car je veux vraiment voir les pixels s'afficher les 1 aprés les autres.

Justement, si tu veux les voir s'afficher, tu auras même intérêt à foutre un QTimer avec un timeout de quelques dizaines/petites centaines de ms pour gérer ton traitement
Il n'y a pas d'accés direct à la zone graphique d'un widget, donc tu es obligé de procéder soit:
> de la façon que tu as décrit (adapté jusqu'à certaines tailles)
> soit, plus court et plus propre: 2x QImage, et tu l'envoies à un widget perso qui dessine directement grâce à QPainter::drawImage dans ta réimplémentation du paintEvent.

Donc c'est pour ça que j'avais aussi pensé à QCanvas (plus rapide ?) mais que j'avais laisser tomber car je n'arrivais déjà pas à afficher les pixels (l'image restait toujours noire).

QCanvas est déprécié depuis Qt4, et est remplacé depuis la 4.2 par les classes QGraphics* (View/Scene/...)
Mais n'est vraiment pas adapté à ce que tu veux.

[mchk0123]

> soit, plus court et plus propre: 2x QImage, et tu l'envoies à un widget perso qui dessine directement grâce à QPainter::drawImage dans ta réimplémentation du paintEvent.

Compris pour le paintEvent + drawImage.
Pour le QTimer, l'idée est trés bonne, je vais seulement le déplacer un peu : un sleep() dans mon moteur de traitement d'image (multi-threadé par rapport à Qt).

Dés que j'ai un exemple de code (s'il ne marche pas) je reviens pour le poster.

Par contre je ne vois pas encore l'intérêt d'avoir 2 QImage s'ils sont tous les deux de type back-buffer ? 1 QImage ne suffirais pas ?

[IrmatDen]

Par contre je ne vois pas encore l'intérêt d'avoir 2 QImage s'ils sont tous les deux de type back-buffer ? 1 QImage ne suffirais pas ?

Non non non! Soit j'ai pas assez insisté sur ce point, soit tu as mal compris (ou surement un mélange des 2 ), mais il n'y a *que*les widgets qui ont un système de double buffer. Un QImage ne contiennent qu'une et une seule image. D'où la nécessité d'avoir 2 instances selon ton travail; je pense particulièrement à des calculs basés sur des matrices de pixel, et où l'image sur laquelle tu travailles doit donc être une autre que celle où tu dessines (imagine le décalage sinon )

[mchk0123]

Arf ... je crois avoir compris.

La première QImage sert de buffer mémoire (réprésentation mémoire).

Je ne penses pas en avoir besoin, car avec ma bibliothèque de traitement d'image j'ai déjà une matrice allouée de m x n de pixels, ce qui serait en double avec la première QImage.

Je penses donc que je vais utiliser qu'une seule QImage.

[IrmatDen]

Oui, c'est bien ça, et dans ces conditions tu n'as effectivement pas besoin de 2 images. Sujet résolu donc?

[mchk0123]

Bon ça y est ça fonctionne !

Par contre j'ai été obligé de déplacer le refresh à l'intérieur d'un timer de 41ms (environ 24 img/s, comme à la télé ).

Au début je l'avais fait pour chaque pixel modifié, bonjour le flickering !

Je considère le sujet résolu. Par contre dommage de ne pas pouvoir peindre directement sur le canvas sans passer par QImage -> QPixmap -> QLabel. Ca aurait surement accéléré l'affichage.

[dimitri-trolltech]

Par contre dommage de ne pas pouvoir peindre directement sur le canvas sans passer par QImage -> QPixmap -> QLabel. Ca aurait sûrement accéléré l'affichage.

Impossible de ne pas passer par la conversion QImage -> Qpixmap dans un toolkit généraliste. Par exemple sur Qt/X11, le QPixmap est sur le serveur X (donc en mémoire vidéo voire sur un autre ordinateur) et QImage est en mémoire normale, directement accessible par le client. Des toolkits comme SDL peuvent court-circuiter ce mécanisme et y gagner en rapidité, mais au dépens de la flexibilité (par exemple affichage distant impossible sous X11).

[mchk0123]

Merci pour ces explications.