Oscilloscope

Bonjour !

J'aurai besoin d'une libraire permettant de faire comme un oscilloscope.
Librairie fonctionnant sous linux ça serait cool .
Je dois faire un programme qui analyse un signal envoyé par usb.
Ce signal il faut que je puisse voir si c'est du 0 ou du 1 (0V pour 0, et sans doute 5V pour 1).
Quelqu'un connait une librairie permettant de faire ça ? si possible un minimum documenté =D

up ?

il te faudra donc deux librairies au minimum alors.
Une qui gère l'usb et l'autre qui gère le graphique.
Pour l'usb
http://www.google.fr/search?hl=fr&sa=X [...] ibusb&spell=1

et pour le graphique Qt??
WxWidget , .....

Qt, je connais un peu, enfin, un peu.
Et j'ai vu aucune fonction qui permettait de faire une decomposition spectrale d'une image ou d'une video.
C'est possible ?

Merci pour l'usb !

je ne pense pas que Qt est capable de faire se genre de chose.
Mais après tu peux le créer toi même.
Il y a QPainter pour dessiner.
http://doc.trolltech.com/4.4/qpainter.html

En gros, tu cherches à traiter un flux vidéo provenant d'une webcam ?

Si c'est le cas, tu peux tout gérer avec la bibliothèque OpenCV d'Intel.
Elle est faite pour ça , le traitement d'images/de vidéos.

Pour les bases d'OpenCV, j'ai un tuto en cours de validation, sinon je te conseille (bien que ça soit en anglais) cette petite introduction aux fonctions de bases.

Continue de poster si t'as des problèmes d'install .

ah, merci !

Je veux traiter la video d'une webcam, sous linux.
Le programme est deja ecrit, et il me sort un autre flux video.
En cherchant un peu je pourrait peut etre le faire sortir comme une deuxieme webcam.
Je voudrais la decomposition spectrale de ce deuxieme flux.

Je sais pas si OpenCV peut faire ça, mais je trouve rien pour faire ça, a part Matlab qui est payant.

Je te conseille de faire des recherches sur la transformée de fourier, ou FFT (fast fourier transform) ca t'aidera a faire une décomposition spectrale de n'importe quoi.

Apparament, c'est pas ce que je cherche.
En fait, faut pas que j'ai le spectre, il me faut juste la luminance.

Je m'explique, je sort un signal par la sortie s-video. On recupere la luminance, et ensuite, on branche ça sur un oscillo, et on voie tres clairement tout mouvement : ça fait un pic.
Je cherche a voir ça sur le PC. De façon apres a compter ces pic.
Parrait que la transformé de fourrier me donne un resultat qui ne me servirai a rien (j'y connais rien en signal, spectre et autre moi, desolé )

ça parait si simple une fois que c'est expliquer. Le temps que j'ai passer a chercher ça -_-'.


Et ben, merci, vraiment ! .

Connaitre le rouge vert bleu d'un pixel, jamais essayé mais bizarement je pense que je vais pas mettre longtemps a trouver .

Alors, dans un premier temps, je detecterai de maniere generale, et quand ça marchera je chercherai par zone pour compter le nombre de zone en mouvement, le but final quand meme.

Les zones mouvantes sont blanches, les autres noires.
La luminance est donc sur 255 + 255 + 255 = 765 ?

Va faloir quelque test pour trouver un seil resonable .

Vraiment, merci =D

La luminance, dans la pratique, c'est pas tout à fait la somme des composantes RVB mais plutot leur moyenne. C'est ce qui permet de dire qu'une image en niveaux de gris ne code que la luminance de chaque pixel sur un octet (entre 0 et 255).

Effectivement OpenCV va pouvoir te permettre de faire ça hyper simplement en C ou C++.
Il permet d'ouvrir un flux d'une caméra, ou un flux vidéo (genre une vidéo en .avi) et d'en traiter toutes les images.

Maintenant, détecter un mouvement simplement en faisant des différences pixel à pixel, c'est simpliste... très simpliste... peut être même trop simpliste : tout simplement parce que le signal d'une webcam, c'est très bruité !

Donc si tes traitements qui sont appliqués avant que tu recoives tes images sont des opérations de lissage, c'est cool !
Sinon tu as 2 solutions :

- Etudier effectivement la différence mais sans oublier de "lisser l'image" (avec OpenCV c'est une fonction toute simple : cvSmooth, tu verras)

- Ou alors calculer le flot optique de l'image (ce qui est très simple aussi avec OpenCV, il le fait pour toi, et on peut trouver de très nombreux exemples codés sur le net).
Le flot optique, c'est ce qui correspond en gros au "vecteur déplacement de chaque pixel de l'image à un instant donné", ce qui t'intéressera certainement beaucoup plus que les simples différences de niveaux de gris (c'est carrément plus robuste).

Voilà. Si tu as des questions sur OpenCV ou les algos de traitement d'image/ de vidéo, n'hésite pas .

Citation : NoHaR
On peut considérer la luminance comme la somme ou la moyenne, ça ne change rien au problème.

Citation : NoHaR
NoHaR a raison lorsqu'il dit qu'il faut considérer le bruit. Pour ca il suffit de ne pas considérer UN pixel mais un paquet de pixels. C'est la raison pour laquelle je t'ai dit que ma méthode marchait sur des paquets de pixels, ou sur toute l'image. Evidement pixel par pixel c'est faux.


Un lissage(comme une convolution par exemple) reviens à faire une moyenne pondérée d'un paquet de pixels, Aux pondérations près ça revient au même que de faire une somme, du coup les deux méthodes vont marcher A condition de:
- prendre un nombre de pixels assez grand pour la méthode de la somme.
- prendre un noyau de lissage assez grand pour la méthode avec lissage.

Si OpenCV te permet de lisser sans avoir à coder, autant utiliser la fonction toute prête. Vérifie juste que le noyau soit assez large.

Quand au flot optique, je ne sais pas ce que c'est.

Oh des méthodes de lissage y'a peut-être plus simple qu'un filtre de convolution (genre flou gaussien), à efficacité au moins équivalente :

En principe un bruit comme celui d'une webcam s'élimine très bien avec un filtre médian . Ceci dit bon conseil ! Utiliser les filtres implémentés nativement dans OpenCV sont les plus rapides que tu pourras coder/utiliser...

Si tu hésites sur le traitement, la fonction cvSmooth te donne le choix entre le filtre médian et le flou gaussien, avec un "noyau" dont tu choisis la taille (3x3, 5x5 , 7x7, éventuellement rectangulaire pour le flou Gaussien), tu pourras les tester toutes les deux et faire un peu ta sauce en changeant les paramètres pour ajuster le traitement à ton cas paticulier.

Citation : ledemonboiteux

Certes !
Cependant considérer la moyenne, c'est déjà comprendre le passage de RGB à NVG, et rester dans la dynamique de l'image...

C'est tout bête, mais ça permet d'afficher ton image "de luminance" (c'est-à-dire en niveaux de gris) sans avoir à faire 1 ou 2 parcours supplémentaires de toute l'image pour la normaliser sur un octet (avec ou non étirement de l'histogramme) .

Quand tu essayes de traiter en temps réel, c'est un argument qui pèse lourd (même avec un flux webcam type, de 640x480 pixels, qui n'est pourtant pas énorme).

Il s'en est passer des choses pendent ce week end dites donc .

Merci a tout les deux !

Je vais me mettre a OpenCV rapidement alors !
Pour le bruit, je m'inquiette pas trop, parce que le programme que j'ai deja s'en occupe, et ce qui reste est ... ridicule. Y a quasiment plus aucun bruit, et ce qui reste, ça se voit pas a l'oeil nu, il faut mettre un oscillo et le mettre asser sensible .

Mais pour pouvoir essayer OpenCV, il va faloir que mon programme mette la video qu'il genere, par exemple dans quelque chose comme /dev/video1, va faloir que je cherche ça !

En tout cas merci, j'avance, c'est cool !

Question comme ça :
C'est quoi en fait le "cahier des charges" de ton programme ?
La finalité c'est de détecter un mouvement ?
Suivre une cible en mouvement ?

Dans un premiers temps, detecter un mouvement "generalement" serait deja bien, parce que ça pourrait enlever toute une partie analogique.

Mais le but final serait quand meme de reussir a compter le nombre d'objet bougeant.

Oui dans ce cas c'est gérable "relativement facilement" (quoique pas évident tout de même) avec une méthode de flot optique.

-> Calculer le flot optique de l'image.
-> Obtenir le champ de mouvement.
-> Repérer les "composantes connexes" (objets d'un seul bloc) qui ont relativement le même mouvement.
-> Les compter.

voici les slides d'un cours de traitement de vidéo qui pourrait t'intéresser .
Edit : Bon c'est plein de maths là dedans, mais vers la slide 97 tu as la description d'une petite appli qui ressemble à ce que tu comptes faire

Justement, je viens de finir mon livre javais plus rien a lire ... xD.
J'ai de quoi lire la ! Merci .
Justement, vendredi n'a quelque centaines de kilometres a faire, je sens que ça va m'occuper.

En tout cas, merci pour toute ces reponses

EDIT : c'est exelent ton truc mais c'est dur a lire .
Mais je commence a me dire qu'on peut surement faire beaucoup plus simple que le programme actuel =)

Commence mal avec OpenCV (cf ici)

A part ça j'ai lu qu'il allait etre asser simple d'arriver a un resultat comme le programme que j'ai deja fait, mais en beaucoup (vraiment beaucoup) moin de ligne.

Sauf que la, ce sera moi qui ai ecrit le programme, donc je m'y retrouverai mieux deja =)