Discussion :

[poukill]

Bonjour à Tous!

Je vais me lancer dans un gros projet ( 18 mois ) sur une analyse d'un phénomène physique très complexe...
L'analyse devra être effectué en temps réel... C'est une analyse événementielle d'images (analyse comportementale)...
Je dois donc détecter des événements anormaux.

J'ai quelques questions à vous poser:
1) Le C++ peut - il convenir à ce genre de tâche? J'ai pour ça un gros PC de calcul sous Windows et Unix si nécessaire.
Quand je programmais sur DSP, c'était du C, mais là j'ai d'autres outils de travail, nettement plus puissants... Alors je ne sais pas trop...

2) Pour afficher les images en temps-réel, montrer les résultats de mes analyses, suivre les phénomènes, quelle bibliothèque utiliser? Pendant mon précédent projet de six mois j'ai utilisé CImg, mais là?
Qt, WxWidget???

Je vous remercie beaucoup pour toutes vos réponses et/ou remarques!!!

[themadmax]

Le traitement d'image temp réel en C++ est possible, cela depand de la taille de la video a analysé et aussi de la complexité de ton traitement. Parfois il faut ecrire des algo en ASM pour optimisé (si cela est possible). Le nouveau truc à la mode est aussi d'utilise le GPU.
Pour ce qui est de l'affichage il existe des lib portable (SDL). Mais il faut savoir que l'affichage prend boucoup de temp, et il faut parfois utiliser des outils plus pres de la machine ( DirectX, OpenGL...)
Je crois pour un projet d'une durée longue, il est difficile d'estimer la rapidité du code. Fait rapidement des maquettes de ton prog pour savoir si l'ordre de gradeur est acceptable.

[JolyLoic]

Le C++ est fait pour des projets où le temps compte. Par contre, quel que soit le langage, tout ce qui est affichage est long, et souvent non déterministe en terme de temps d'exécution. Il est donc préférable de bien séparer traitement et affichage, de façon à effectuer ces derniers dans une tâche à faible priorité.

En plus du langage, il te faudra aussi choisir ton OS. Ni Windows ni les Unix classiques ne sont temps réels. Si louper de temps en temps tes contraintes de temps n'est pas très grave (temps réel mou), et que ces contraintes sont de l'ordre de quelques millisecondes, ils peuvent quand même convenir. Si ce n'est pas le cas, il faudra te tourner vers un véritable OS temps réel. Ce qui risque de limiter le choix de langage, le C++ n'étant pas disponible (ou pas bien supporté, ou buggé) sur certains de ces OS.

[poukill]

Le C++ est fait pour des projets où le temps compte. Par contre, quel que soit le langage, tout ce qui est affichage est long, et souvent non déterministe en terme de temps d'exécution. Il est donc préférable de bien séparer traitement et affichage, de façon à effectuer ces derniers dans une tâche à faible priorité.

En plus du langage, il te faudra aussi choisir ton OS. Ni Windows ni les Unix classiques ne sont temps réels. Si louper de temps en temps tes contraintes de temps n'est pas très grave (temps réel mou), et que ces contraintes sont de l'ordre de quelques millisecondes, ils peuvent quand même convenir. Si ce n'est pas le cas, il faudra te tourner vers un véritable OS temps réel. Ce qui risque de limiter le choix de langage, le C++ n'étant pas disponible (ou pas bien supporté, ou buggé) sur certains de ces OS.

D'accord Loïc pour la séparation traitement et affichage.

Ensuite, je ne pense pas être dans le temps réel pur, à compter le nombre de cycles de calcul... Je pênse que le temps réel mou fera l'affaire, je ne suis pas à la milliseconde...

[Mat.M]

Tu parles de SDL je trouve cette API très lente voire plus par rapport au simple GDI parfois sous Windows.
SI tu veux des performances faut accèder à des API natives comme Direct X ou simple GDI sous Windows je ne recommande pas trop les "wrappers"
Et puis l'OS a son importance comme le dit Loic Joly.
Vaut mieux un OS véritablement temps réel comme par exemple QNX

[buzzkaido]

Moi je dirais comme les autres :

- si tu as une contrainte forte sur le temps réel => OS temps réel, y'a que ça

- si tu as une contrainte "molle" sur le temps réels => au mieux un linux specialement optimisé, au pire un windows spécialement optimisé (un minimum de services qui tournent...)

Dans le deuxieme cas, que tu soit sous windows ou linux :

- un processus haute priorité pour le traitement, avec des algos bien pensés, bien optimisés, avec pour les parties les plus critiques un peu d'assembleur

- un processus faible priorité pour l'affichage, si possible avec le choix entre 2 ou 3 tailles/qualités d'affichage (pour accelerer si besoin). Pour l'affichage, rien de plus simple et de plus rapide que le GDI (à mon avis) si tu souhaites uniquement afficher des images (pas de calcul 3D...)

En tout cas, si ton but est la vitesse et pas l'ergonomie, evites les grosses bibliotheques graphiques qui vont t'ajouter des centaines de lignes de codes dont tu n'as rien à faire pour avoir juste une fenetre avec une image et un bouton "start"

Dans tous les cas, rien ne t'empeche d'utiliser une carte à DSP pour booster le tout, ou alors d'utiliser les fonctions specifiques du GPU pour accelerer le traitement sur les images.

Par exemple (je suis pas à 100% sur, mais en gros) :
Mettons que dans ton traitement temps réel tu ai besoin d'appliquer un filtre 9x9 sur ton image, tu peux utiliser directX pour ça. Du coup, si la carte graphique sait appliquer des filtres 9x9, c'est elle qui va le faire, et c'est autant de ressources economisées sur le CPU....

[poukill]

Pour l'instant, je n'ai aucune idée des traitements à effectuer.
C'est sur que dans un premier temps, je vais plutôt m'occuper des algos à développer...

Le but ici est de voir quels sont les outils qui peuvent être à ma disposition.
J'ai déjà utiliser un peu la SDL, mais pas Qt, ni WxWidget.

Pour le temps réel, une lib pas trop gourmande serait la bienvenue!
A moins que le GPU prenne le relais. J'imagine que pour l'affichage graphique, l'utilisation du GPU serait un plus, mais est-ce différent alors comme manière de programmer?

Merci !

[JeitEmgie]

Bonjour à Tous!

Je vais me lancer dans un gros projet ( 18 mois ) sur une analyse d'un phénomène physique très complexe...
L'analyse devra être effectué en temps réel... C'est une analyse événementielle d'images (analyse comportementale)...
Je dois donc détecter des événements anormaux.

J'ai quelques questions à vous poser:
1) Le C++ peut - il convenir à ce genre de tâche? J'ai pour ça un gros PC de calcul sous Windows et Unix si nécessaire.
Quand je programmais sur DSP, c'était du C, mais là j'ai d'autres outils de travail, nettement plus puissants... Alors je ne sais pas trop...

2) Pour afficher les images en temps-réel, montrer les résultats de mes analyses, suivre les phénomènes, quelle bibliothèque utiliser? Pendant mon précédent projet de six mois j'ai utilisé CImg, mais là?
Qt, WxWidget???

Je vous remercie beaucoup pour toutes vos réponses et/ou remarques!!!

Avez-vous mesurer les quantités de données manipulées ?
Quels sont les "circuits" suivi par ces données et quelles sont les débits possibles tout au long ce ces circuits ?
Quelles ont les transformations (calculs) des données que vous devez effectués ?
Avez-vous fait des benchmarks de ces calculs ?
Vous parlez d'images : ce sont des images acquises (quelle interface hardware ? (débit ?), dimension, résolution, profondeur, faut-il convertir les espaces couleurs au vol ? …) qui doivent être manipulées ou simplement des graphiques déduits de vos calculs ?
Si ce sont des graphiques, il faudra analyser la répartition entre les parties "fixes" (invariant d'un frame à l'autre) et les parties "variables"…
Les résultats intermédiaires doivent-il être sauvés sur disque ? Quantité ?

etc.

l'analyse de la faisabilité d'une application "temps réel" commence par la définition de la notion de "temps réel" pour le contexte donné…
et ensuite il faut déterminer tous les chemins suivis par les données,
examiner le parallélisme logique, voir s'il peut se traduire par un parallélisme physique et examiner sur les différents chemins obtenus quels sont les débits possibles, voir s'il y a des conditions de compétition pour certaines resources à certains moments (CPU, mémoire, bus accès GPU, disque, GPU, interfaces vers l'hardware d'acquisition, …), bref déterminer le chemin critique…
(entre devoir faire des grosses FFT en temps réel et acquérir de l'HDTV les "bottlenecks" ne seront pas au même endroit : dans le premier cas, la conclusion pourrait être qu'il faut un multi-processeur dont chaque cpu a sa propre cache d'accès à la RAM, dans l'autre qu'il faut une carte graphique qui permette les meilleurs transferts DMA possibles, un RAID SCSI haut de gamme et un OS qui permette de copier la mémoire d'acquisition video directement dans celle du GPU sans copie intermédiaire…)


… vous avez posé une question relativement vague…
et à mon avis les réponses obtenues, même si elles peuvent être correctes dans un contexte donné, le sont tout autant car il manque essentiellement une vue d'ensemble de ce que vous devrez faire et ne fusse qu'un pré-analyse des "coûts" de chaque étape…

[poukill]

Avez-vous mesurer les quantités de données manipulées ?
Quels sont les "circuits" suivi par ces données et quelles sont les débits possibles tout au long ce ces circuits ?
Quelles ont les transformations (calculs) des données que vous devez effectués ?
Avez-vous fait des benchmarks de ces calculs ?
Vous parlez d'images : ce sont des images acquises (quelle interface hardware ? (débit ?), dimension, résolution, profondeur, faut-il convertir les espaces couleurs au vol ? …) qui doivent être manipulées ou simplement des graphiques déduits de vos calculs ?
Si ce sont des graphiques, il faudra analyser la répartition entre les parties "fixes" (invariant d'un frame à l'autre) et les parties "variables"…
Les résultats intermédiaires doivent-il être sauvés sur disque ? Quantité ?

etc.

l'analyse de la faisabilité d'une application "temps réel" commence par la définition de la notion de "temps réel" pour le contexte donné…
et ensuite il faut déterminer tous les chemins suivis par les données,
examiner le parallélisme logique, voir s'il peut se traduire par un parallélisme physique et examiner sur les différents chemins obtenus quels sont les débits possibles, voir s'il y a des conditions de compétition pour certaines resources à certains moments (CPU, mémoire, bus accès GPU, disque, GPU, interfaces vers l'hardware d'acquisition, …), bref déterminer le chemin critique…
(entre devoir faire des grosses FFT en temps réel et acquérir de l'HDTV les "bottlenecks" ne seront pas au même endroit : dans le premier cas, la conclusion pourrait être qu'il faut un multi-processeur dont chaque cpu a sa propre cache d'accès à la RAM, dans l'autre qu'il faut une carte graphique qui permette les meilleurs transferts DMA possibles, un RAID SCSI haut de gamme et un OS qui permette de copier la mémoire d'acquisition video directement dans celle du GPU sans copie intermédiaire…)


… vous avez posé une question relativement vague…
et à mon avis les réponses obtenues, même si elles peuvent être correctes dans un contexte donné, le sont tout autant car il manque essentiellement une vue d'ensemble de ce que vous devrez faire et ne fusse qu'un pré-analyse des "coûts" de chaque étape…

Je sais bien que ma question est vague...
Cependant, les réponses qui me sont apportées ici me sont très utiles pour éliminer des pistes.
Le projet ici est beaucoup plus conséquent que tout ce que j'avais vu à présent. Je pars de pas grand chose (bcp à défricher !!), et mes connaissances en développement sérieux et propre restent largement à parfaire, notamment sur du temps-réel (mou ici) multi-tâches

Beaucoup d'habitués ici connaissent bien que moi les outils disponibles, ainsi que les différentes façons d'attaquer mon problème.

Je peux quand même donner plus de précision :

image : 320 * 240
Période d'échantillonnage : 20 ms
Durée du film : 30 secondes environ

La détection d'événements anormaux (algos pour l'instant complètement indéfinis, c'est le but du projet) devra permettre de stopper l'expérience (asservissement sur un circuit physique)

Voilà, j'espère être plus précis!