Carte d'acquisiton, capture signal vidéo et traitement tp réel ??

Carte d'acquisiton, capture signal vidéo et traitement tp réel ?? - C++ - Programmation

Marsh Posté le 13-06-2008 à 16:20:51    

Bonjour à tous  :hello: ,  
 
Je suis actuellement en stage et on me demande de concevoir un programme de traitement de flux vidéo en temps réel. Schématiquement, je dois récupérer un flux vidéo s-vidéo (ou VGA mais je ne connais pas de carte d’acquisition pour du VGA…) sur mon PC, je bidouille l’image et je dois l’afficher l’image modifiée le plus rapidement possible à l’écran. Je n’ai jamais fait cela auparavant  :sweat: , et j’apprécierai grandement votre aide pour déterminer le matériel, le langage et les librairies adaptés.  
J’avais pensé à C++ avec les lib Open CV pour le traitement d’images et QT pour l’interface. Par contre je n’ai aucune idée du matériel que je dois choisir et du moyen pour récupérer les frames à partir du flux vidéo. Y a-t-il un model  particulier de carte d’acquisition (de préférence en USB) à choisir en priorité ? Quelles librairies, ou comment s’y prendre pour récupérer le flux vidéo en temps réel ?
 
Merci d’avance pour votre aide  :jap:  

Reply

Marsh Posté le 13-06-2008 à 16:20:51   

Reply

Marsh Posté le 13-06-2008 à 17:55:36    

Sous Windows, c'est DirectShow qu'il faut utiliser pour la capture et l'affichage.


Message édité par bjone le 13-06-2008 à 17:56:15
Reply

Marsh Posté le 13-06-2008 à 18:39:34    

cool, merci pour l'info  :jap: . Faut il choisir un matériel particulier pour faciliter les choses ou peut importe ?

Reply

Marsh Posté le 14-06-2008 à 09:08:54    

Salut !
 
   Je connais pas bien OpenCV, mais je sais qu'il est possible de faire aussi la partie capture de la vidéo au sein de cette librairie. Ca te permettrai d'avoir un truc qui soit beaucoup plus portable que si tu utilisait DirectShow.
   Ici, tu as un bout de de doc : http://www.cs.iit.edu/~agam/cs512/ [...] intro.html
Bon, je pense que tu peux trouver mieux, mais ça expliquait déjà comment faire la capture du flux vidéo (et l'affichage également).
 
En ce qui concerne le matériel j'ai envis de dire peu importe, c'est le rôle de l'OS de faire une abstraction du matériel utilisé...
 
voila, bon courrage :)

Reply

Marsh Posté le 14-06-2008 à 22:15:10    

Pour avoir galéré (en stage aussi) avec des webcams logitech, openCV, V4l dans le passé, voici mon conseil :
 
Prendre une cam firewire. C est un standard bien répandu et correctement implémente, ce qui tend a limiter les comportements inexplicables en terme de framerate par exemple (genre la camera ajuste son temps d exposition automatiquement ou autre, de maniere masquee dans le driver)
 
Il me semble qu on peut trouver des petites webcams firewire a environ 100 euros : ensuite http://damien.douxchamps.net/ieee1394/libdc1394/ .  
 
Bon tout ca c est pour faire de la recherche et des traitements serieux en aval. Autrement dit, pour perdre le moins de temps possible avec le hardware et les API et se concentrer sur les algos.  Si ton projet est de pondre un soft qui va tourner sur un max de configurations, je te conseille de ne meme pas aller voir openCV et de prendre la doc directshow directement (car en plus openCV a plusieurs modules d acquisition, qui de toute facon sous win sont bases sur directX)

Reply

Marsh Posté le 15-06-2008 à 11:24:48    

chewif a écrit :

Si ton projet est de pondre un soft qui va tourner sur un max de configurations, je te conseille de ne meme pas aller voir openCV et de prendre la doc directshow directement


 
Tu pourrai justifier pourquoi tu dit ça ? Je suis pas un partisan d'OpenCV, mais j'aimerai bien savoir ce que tu lui reproche. Je l'ai juste utilisé pour quelques ptits truc donc j'ai pas vraiment eu de problème (c'était juste relou de configurer les path de l'IDE vu qu'il y a plein de sous parties :D). Mais sinon, tu lui reproche quoi ? Il est gourmand en ressources ?
 
Après en ce qui concerne le fait qu'OpenCV utilise DirectShow sous windows, c'est pas vraiment la question. Moi, je dit juste que si un jour il veut passer sous Linux ou MacOS, en utilisant opencv il aura juste a recompiler sans retoucher la moindre ligne de code, ce qui est qqch d'intéressant... Je sais que mes proff utilisent ça dans leurs labo, comme ça ils ont pas de soucis entre ceux qui travaillent sous linux/mac/win...
 
Mais après peut-être que ce qu'il fait ne quittera jamais l'environnement Windows...

Reply

Marsh Posté le 15-06-2008 à 12:01:37    

les seuls reproches qu'on peut faire à OpenCV c'est sa non-modularité, son choix parfois moche des algos haut niveau et son déploiement parfois complexe.

Reply

Marsh Posté le 15-06-2008 à 13:04:55    

Amonchakai a écrit :


 
Tu pourrai justifier pourquoi tu dit ça ? Je suis pas un partisan d'OpenCV, mais j'aimerai bien savoir ce que tu lui reproche. Je l'ai juste utilisé pour quelques ptits truc donc j'ai pas vraiment eu de problème (c'était juste relou de configurer les path de l'IDE vu qu'il y a plein de sous parties :D). Mais sinon, tu lui reproche quoi ? Il est gourmand en ressources ?
 
Après en ce qui concerne le fait qu'OpenCV utilise DirectShow sous windows, c'est pas vraiment la question. Moi, je dit juste que si un jour il veut passer sous Linux ou MacOS, en utilisant opencv il aura juste a recompiler sans retoucher la moindre ligne de code, ce qui est qqch d'intéressant... Je sais que mes proff utilisent ça dans leurs labo, comme ça ils ont pas de soucis entre ceux qui travaillent sous linux/mac/win...
 
Mais après peut-être que ce qu'il fait ne quittera jamais l'environnement Windows...


 
Je n  ai pas condamné les modules d acquisition d openCV. Sur un stage court de prototypage d algo ca peut etre valable, mais l argument de la portabilite est relativement limite quand on voit le merdier que sont les drivers de webcams. A l epoque de mon stage quelques cams utilisant l USB Video Class commencaient a sortir, ce qui laissait espérer une progressive uniformisation de tout ca. Je ne sais pas ou ca en est maintenant.
 
On ne sait toujours pas de quoi retourne ce stage. Possiblement, il est dans une boite qui cherche a déployer un petit jeu utilisant un flux video en entree, auquel cas il a plutot interet a coder ca en directX. Si il est dans un labo de recherche, il est etonnant que les permanents n aient pas de solution de capture pour leur matos et leur environnement de dev. (meme si ca a aussi ete mon cas pendant mon stage dans un labo dont l activite n etait pas historiquement la vision), auquel cas je leur conseille encore une fois de prendre des cams firewire pour minimiser les emmerdements ( puisque c est ce qu utilisent les labos de CV avec qui je bosse )

Reply

Marsh Posté le 15-06-2008 à 14:28:23    

Ok, merci pour ces explacations :)

Reply

Marsh Posté le 17-06-2008 à 17:00:30    

Amonchakai a écrit :

Salut !
 
   Je connais pas bien OpenCV, mais je sais qu'il est possible de faire aussi la partie capture de la vidéo au sein de cette librairie. Ca te permettrai d'avoir un truc qui soit beaucoup plus portable que si tu utilisait DirectShow.
   Ici, tu as un bout de de doc : http://www.cs.iit.edu/~agam/cs512/ [...] intro.html
Bon, je pense que tu peux trouver mieux, mais ça expliquait déjà comment faire la capture du flux vidéo (et l'affichage également).
 
En ce qui concerne le matériel j'ai envis de dire peu importe, c'est le rôle de l'OS de faire une abstraction du matériel utilisé...
 
voila, bon courrage :)


 
Alors si OpenCV me permet de tout faire, c'est royal ! Merci à toi pour l'info et l'URL ;)
 
 

Citation :


Pour avoir galéré (en stage aussi) avec des webcams logitech, openCV, V4l dans le passé, voici mon conseil :
 
Prendre une cam firewire. C est un standard bien répandu et correctement implémente, ce qui tend a limiter les comportements inexplicables en terme de framerate par exemple (genre la camera ajuste son temps d exposition automatiquement ou autre, de maniere masquee dans le driver)
 
Il me semble qu on peut trouver des petites webcams firewire a environ 100 euros : ensuite http://damien.douxchamps.net/ieee1394/libdc1394/ .  
 
 
 
Bon tout ca c est pour faire de la recherche et des traitements serieux en aval. Autrement dit, pour perdre le moins de temps possible avec le hardware et les API et se concentrer sur les algos.  Si ton projet est de pondre un soft qui va tourner sur un max de configurations, je te conseille de ne meme pas aller voir openCV et de prendre la doc directshow directement (car en plus openCV a plusieurs modules d acquisition, qui de toute facon sous win sont bases sur directX)


 
:hello:
Je ne vais pas utiliser une web cam mais un flux vidéo s-video. Mon thème de stage a pour objectif la poursuite de deux travaux de thèses visant à améliorer la détection des nerfs en échographie. On me demande de programmer un logiciel de traitement en temps réel de l'échographe. Je dois donc capturer la vidéo en temps réel, appliquer un filtre et afficher à l’écran les images modifiées. La machine est la suivante : http://france.sonosite.com/MicroMAXX/MicroMAXX.php il y a pas mal de sorties (VGA, S-video, composite, USB, Ethernet avec format DICOM, enregistrement sur Compact Flash). Je vais essayer de faire quelques tests avec l’Ethernet mais ce n’est indiqué nul par dans la doc si je peux capturer la vidéo en temps réel. Il semblerait que cela serve uniquement à télécharger les séquences vidéo enregistrées sur l’échographe.  
A part peut être l’Ethernet, visiblement seuls les sorties VGA, S-video et composite permettent de récupérer le flux vidéo en temps réel.
Voila pourquoi j’ai besoin d’une carte d’acquisition.  
 L’application devra tourner sur 2 ou 3 PC tout au plus.  
 
 
 

Citation :

Je n  ai pas condamné les modules d acquisition d openCV. Sur un stage court de prototypage d algo ca peut etre valable, mais l argument de la portabilite est relativement limite quand on voit le merdier que sont les drivers de webcams. A l epoque de mon stage quelques cams utilisant l USB Video Class commencaient a sortir, ce qui laissait espérer une progressive uniformisation de tout ca. Je ne sais pas ou ca en est maintenant.  
 
On ne sait toujours pas de quoi retourne ce stage. Possiblement, il est dans une boite qui cherche a déployer un petit jeu utilisant un flux video en entree, auquel cas il a plutot interet a coder ca en directX. Si il est dans un labo de recherche, il est etonnant que les permanents n aient pas de solution de capture pour leur matos et leur environnement de dev. (meme si ca a aussi ete mon cas pendant mon stage dans un labo dont l activite n etait pas historiquement la vision), auquel cas je leur conseille encore une fois de prendre des cams firewire pour minimiser les emmerdements ( puisque c est ce qu utilisent les labos de CV avec qui je bosse ).


Je suis dans un labo de recherche universitaire spécialisé en « Human Factors ». C’est la première fois qu’ils veulent effectuer ce type de capture vidéo (via carte d’acquisition). Ils ont déjà réalisés des applications pour d’autres projets avec effectivement des caméras en firewire et à chaque fois C++ a été utilisé avec la lib Open CV. Je n’ai hélas pour le moment pas accès aux sources.  
Pensez vous que Open CV soit également approprié pour une capture via une carte d’acquisition ? On m’a également parlé de la lib vfw.h ? Est-elle plus intéressante dans mon cas ?
 
 
 
Merci à tous pour toutes les infos :jap:


Message édité par electric_snake le 17-06-2008 à 17:02:54
Reply

Marsh Posté le 17-06-2008 à 17:00:30   

Reply

Marsh Posté le 17-06-2008 à 17:12:42    

vfw, c'est video for windows, l'ancienne techno de microsoft, ça a été remplaçé par directshow.
 
donc directshow si tu est sous windows uniquement et que tu as besoin d'un accès plus bas-niveau, ou autrement OpenCV ou autre.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed