Discussion :

[TheGzD]

Bonjour à tous !

J'aurai aimé savoir si quelqu'un savait comment faire pour rediriger le flux d'une webcam directement dans un composant MFC (ou un autre composant d'une autre bibliothèque de la sorte) ?

En effet :
- je dois utiliser simultanément plusieurs webcams
- mon acquisition vidéo doit se faire dans un thread, et ce thread ne doit pas gérer l'UI sinon une manipulation sur l'affichage bloque l’acquisition

Actuellement j'utilise la méthode imshow qui a pour inconvénient de créer une nouvelle fenêtre par flux, donc j'ai plusieurs fenêtres qui sont de surcroit dépendantes les unes des autres ... tout sauf ce que je voudrai quoi.

Merci d'avance.

[math_lab]

Il n'y a pas a rediriger de flux. C'est a toi d’arrêter de l'afficher avec ton imshow et d'apprendre a l'afficher dans ton système d'interface graphique. Comme je ne connais rien en interfaces graphique, tout ce que je peux te dire, c'est que tu dois aller dans ta cv::Mat et récupérer le pointeur sur les données pour ensuite faire un peu de magie si nécessaire (conversion de couleurs et autres) et coller le tout dans ton composant.

[TheGzD]

Il n'y a pas a rediriger de flux. C'est a toi d’arrêter de l'afficher avec ton imshow et d'apprendre a l'afficher dans ton système d'interface graphique. Comme je ne connais rien en interfaces graphique, tout ce que je peux te dire, c'est que tu dois aller dans ta cv::Mat et récupérer le pointeur sur les données pour ensuite faire un peu de magie si nécessaire (conversion de couleurs et autres) et coller le tout dans ton composant.

Merci pour ta réponse, mais non ce n'est pas bon du tout à commencer parce que mon acquisition se fait dans un thread disjoint de l'affichage.

Et puis si je dois aller récupérer une sorte de bitmap dans un objet Mat pour le recopier dans mon composant je vais commencer à légitimement me poser la question de l'utilité d'OpenCV ...

[supernovagm]

avec Qt et sa gestion des threads tu peux t'en sortir.
Tu lance un thread par caméra.
La caméra est lue avec openCV, puis l'image "openCV" est transformé en image Qt (QImage), enfin tu affiche l'image (repaint).

L'avantage c'est que en plus d'avoir directement l'accés aux webcam, tu peux appliquer ton traitement d'images vidéo openCV avant de donner l'image à Qt pour l'affichage.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
OPENCV
acquisition + traitement vidéo
 
Qt
affichage + gestion de fenêtre (bouton, etc)

[vravier]

Et puis si je dois aller récupérer une sorte de bitmap dans un objet Mat pour le recopier dans mon composant je vais commencer à légitimement me poser la question de l'utilité d'OpenCV ...

Le but principal d'OpenCV n'est pas de faire de la capture, mais du traitement d'image (contraste, luminosité, binarisation, détection de contour, reconnaissance de forme, classification, etc). Les fonctionnalités de capture sont présentes, évitant le recours à une autre lib, mais avec le strict minimum permettant de couvrir la plupart des utilisations. D'ailleurs, le code pour la capture provient de la librairie videoInput.
Si ton objectif premier est de faire de l'UI, effectivement, OpenCV n'est peut-être pas la lib la plus appropriée. Au mieux, il te faudra effectivement récupérer les images que te renvoie OpenCV pour ensuite les convertir et les afficher avec une vraie lib prévue pour de l'UI. Ce que j'avais fait dans un projet de test avec GTK.

[TheGzD]

Merci pour vos réponses.

Oui, je comprends bien que OpenCV n'est pas une bibliothèque de capture vidéo, par contre comme tu le dis elle est destinée au traitement d'images.
Dans bien des cas de traitements le résultat du traitement est une nouvelle image, ce qui dans le cas d'un flux vidéo (qui n'est qu'une succession d'images) revient à vouloir un flux vidéo en sortie. Si après je ne peux pas afficher ce résultat comme je l'entends ça me pose vraiment problème.

Concernant les différentes techniques de conversion de l'image avant affichage ce qui me dérange c'est que mon traitement vidéo s'effectue derrière un thread MFC. Donc je risque d'avoir des soucis pour que l'affichage reçoive les images dans le bon ordre (si je "pousse" les données l'affichage) ou il faudra que l'affichage vienne lire dans la mémoire du thread (si l'affichage vient "tirer" les données) à pas de temps plus ou moins régulier ... dans les 2 cas ça ne me semble ni très classe ni très sûr comme méthodes ... après je peux me tromper.

[vravier]

L'utilisation de thread n'est pas problématique en soi. Bien au contraire, dès que tu veux paralléliser certaines taches, c'est, je pense, l'approche la plus naturelle. On peut imaginer dans ton cas avoir 3 threads:
- acquisition
- traitement
- affichage
Et même pourquoi pas plusieurs threads pour le traitement car c'est a priori celui-ci qui va être un goulot d'étranglement.
Il faut juste bien gérer les accès mémoire correctement et éventuellement utiliser des mutex où il faut. Pour les détails de l'implémentation, c'est à toi de voir ensuite.

[TheGzD]

L'utilisation de thread n'est pas problématique en soi. Bien au contraire, dès que tu veux paralléliser certaines taches, c'est, je pense, l'approche la plus naturelle. On peut imaginer dans ton cas avoir 3 threads:
- acquisition
- traitement
- affichage
Et même pourquoi pas plusieurs threads pour le traitement car c'est a priori celui-ci qui va être un goulot d'étranglement.
Il faut juste bien gérer les accès mémoire correctement et éventuellement utiliser des mutex où il faut. Pour les détails de l'implémentation, c'est à toi de voir ensuite.

Merci mais ça ne répond absolument pas à ma question et je suis déjà conscient de tout ceci. J'ajouterai même que dans le cas d'une application temps réel il n'est pas forcément judicieux de séparer acquisition et traitement afin d'éviter un engorgement de données.

Pour en revenir à mon problème je me suis tourné vers la solution qui consiste à convertir mon image de type IplImage dans un type d'images propre à l'API graphique utilisée. Cette dernière servira de buffer avant affichage ... en clair une grosse perte de temps pour un truc qui était déjà fait pas l'API (via imshow par ex.).

[Jérôme.L]

Bonjour,

Les données bruts d'une iplimage sont accessible via le pointeur "imageData".
( monIplimage->imageData)
Ces données bruts d'image sont communes à d'autres formats d'image.
Je ne connais pas le MFC mais tu pourrais déclarer un objet graphique chargé de contenir l'image.
Rediriger l'adresse vers laquelle pointe les données brut d'image ou alors les recopier dans le nouveau composant.
Si le format n'est pas le même les données de imageData sont triées comme ceci pour une image à 3 channels imageData[nombre de pixel * nombre de channels]: pixel1 bleu, pixel1 vert, pixel1 rouge, pixel2 bleu...
Comme ça si tu connais le format d'arrivée tu peux convertir ton image sans problème avec uniquement 2 boucles for imbriquées.

Tu ne peux pas rediriger un flux : Tu ouvres ta ou tes caméra avec OpenCV tu récupères les images et tu les traites de manière itérative.
Ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
capture.open()
while()
{
capture.grab();
capture.retrieve(frame);
afficher(frame);
}

Pour le thread je ne vois pas le problème.
Tu pourrais par exemple appeler ton thread avec ton objet chargé d'afficher l'image en paramètre.
ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

hProcessThread = pthread_create(&threadVideo, NULL,&MaClasse::threadDemarrerVideo, this->MFCObjetAffichage);

Dans ton thread tu réalises l'acquisition, le traitement et tu envoies le résultat vers " this->MFCObjetAffichage"

J'aurais aimé pouvoir t'aider plus, mais aussi tu faits du MFC donc c'est ta faute
Qt vaincra

[TheGzD]

Merci pour les règles des conversions, c'est celles que j'avais aussi trouvé

Le problème avec les threads c'est qu'ils sont dans une DLL. Le programme principal charge quant à lui cette DLL et appelle ses différents points d'entrée.
Donc dans le contexte de mon histoire, ça oblige à renvoyer des pointeurs explicites sur les images contenues sur le tas propre de la DLL ... pas très classe quoi. Et pour bien faire je dois développer une couche de protection d'accès aux données avec des sémaphores et autres sections critiques, ce qui ne m'enchante pas plus que ça.

[Jérôme.L]

Le problème avec les threads c'est qu'ils sont dans une DLL

Quoi ?

des pointeurs explicites sur [...] la DLL

Quoi ? Quoi ?

Je pensais pouvoir aider puisque le problème concerne OpenCV... mais tes problèmes viennent du MFC.

Je veux pas donner l'impression de prêcher un truc du genre MFC c'est que Windows en plus c'est que pour Visual Studio vive les trucs libre tati tutu...

Mais d'un point de vue qualité uniquement MFC c'est une surcouche mal faite en pseudo objet, des restrictions énorme, des possibilités limitées et des bugs fréquent puisque le problème de ce pseudo objet c'est que justement les objets ne sont pas alloués en temps réel.

Si tu veux le code avec Qt je te fait ça en 10 minutes^^
Si tu as besoin d'aide sur un problème OpenCV sans MFC je pense pouvoir t'être plus utile.

[TheGzD]

Tout d'abord merci à tous pour votre aide

J'ai résolu mon problème en intégrant un peu de tout ce dont nous avons parlé.

Au final j'ai donc :
- 1 thread qui utilise OpenCV (qui à son tour instancie X threads) et met les données dans une structure que j'ai défini
- 2 thread pour l'UI : le thread principale de la fenêtre et un qui lit la structure et affiche la vidéo dans une fenêtre fille dans la fenêtre principale

Si ça intéresse quelqu'un n'hésitez pas à me demander plus de précisions

[heros2.71]

Tout d'abord merci à tous pour votre aide

J'ai résolu mon problème en intégrant un peu de tout ce dont nous avons parlé.

Au final j'ai donc :
- 1 thread qui utilise OpenCV (qui à son tour instancie X threads) et met les données dans une structure que j'ai défini
- 2 thread pour l'UI : le thread principale de la fenêtre et un qui lit la structure et affiche la vidéo dans une fenêtre fille dans la fenêtre principale

Si ça intéresse quelqu'un n'hésitez pas à me demander plus de précisions

Salut,
Peux tu mettre le code source s.t.p.
Je n'arrive pas et faire fonctionner les threads. Merci

[TheGzD]

Bonjour,

Le code concernant quelle partie ?
Le sujet de ce post est vaste et si tu rencontres un problème avec les threads ça n'a rien à voir avec OpenCV.
Tu trouveras d'ailleurs les informations dont tu sembles avoir besoin dans la FAQ Visual C++.



PS : Je ne réponds pas aux questions techniques posées par MP/mail, merci de ta compréhension ...

[heros2.71]

Bonjour,

Le code concernant quelle partie ?
Le sujet de ce post est vaste et si tu rencontres un problème avec les threads ça n'a rien à voir avec OpenCV.
Tu trouveras d'ailleurs les informations dont tu sembles avoir besoin dans la FAQ Visual C++.



PS : Je ne réponds pas poser aux questions techniques par MP/mail, merci de ta compréhension ...

Bonjour,
En deux mots je vous explique la problématique:

• Application Qt
• Carte d'acquisition vidéo Matrox morphis
• Caméra analogique
• Librairie Mil Lite

J'ai trois tâche à effectuer.

1. Acquisition de l'image, que j'ai reussi avec OpenCV
2. Traitement d'image, j'utilise OpenCV
3. L'affichage, aussi avec OpenCV

Mon problème et que l'image n'est pas fluide (j'ai utilisé seulement les signals/slots). Je ne sais pas si en utilisant des thread mon problème sera résolu.
Merci de votre aide.