Bonjour,
Mon but est de traiter une image issue d'une webcam pour en afficher une représentation sur du matériel (par exemple une matrice de leds ou une matrice de moteur etc...) piloté par Arduino.
Au passage je suis débutant dans les deux domaines ! (PD et Arduino)
Mon idée de base est donc de récupérer l'image d'une webcam sur un PC (sous linux), traiter l'image et envoyer le résultat à l'arduino par port série lequel traitera ces infos pour piloter une matrice de leds par exemple.
Mon idée de départ est donc de décomposer l'image recue en nombre de points équivalent au matériel utilisé. Par exemple si j'utilise une matrice de 40 x 40 leds je vais "dégrader" mon image de webcam en 40 x 40 pixels (ou carrés), en gros une mosaique.
Ca donne donc :
- récupérer l'image
- passer en valeurs de gris
- transformer en mosaique 40 x 40
- envoyer les valeurs (luminosité) de chaque carré de la mosaique à l'arduino par port série.
- afficher l'image sur la matrice (chaque led ayant une luminosité proportionelle à la valeur du carré)
Voila. Donc mon pb se trouve sur PureData. J'utilise GEM. J'arrive bien à récupérer l'image webcam, je la passe bien en valeur de gris (objet pix_grey) mais je ne trouve pas le moyen de transformer cette image en mosaique, disons que je ne sais pas par quel moyen passer. Existe-t-il un objet pour ca ? sinon comment faire ?
je joins 2 images qui sont une idée de ce que j'aimerais obtenir apr-s traitement de l'image.
Merci à tous.
Hors ligne
Bonsjours et bienvenue...
Le plus simple, si tu es débutant est de passer par un [pix_resize] en collant un [quality 0( à la texture...
Après, il existe une solution avec [gemframebuffer]... mais si la première te convient, oublie...
Bon courage...
Hors ligne
Écoute...
J'ai fait ça récemment pour parcourir une image afin de choper ses valeurs colorimétriques...
Je n'ai même pas eu à changer les valeurs, c'était du 40x40...
Si tu ne veux écouter que les valeur en niveau de gris, la sortie droite de [pix_data] te le permet...
Bon courage...
EDIT: le [makesymbol ] sert à une autre partie de mon patch que je t'épargne volontairement si tu es débutant...
EDIT 2 : @Rep :
Dernière modification par Olivier (2012-04-27 20:03:15)
Hors ligne
Il y a un shader qui est envoyé dans la discussion sur les shaders : il y a un pixelate puissant en glsl, à mon avis tu en tireras de bons résultats. :-) tu télécharges la librarie a_shad, et tu regares le fichier 0_0 qavec tous les helps.
Dernière modification par philippe boisnard (2012-04-27 23:54:49)
Hors ligne
Ouah ! la vache ! eh ben c'est actif ici, ça fait plaisir !
Merci à tous pour ces quelques pistes que je vais m'empresser d'explorer.
@Olivier : merci pour ce patch dont je ne comprend que les 3 premiers objets mais ça fera un très bon exemple à décortiquer pour aller plus loin !
Je vais néanmoins commencer avec [pix_resize] histoire de voir ce que ça peut donner.
D'ailleurs au passage, mais c'est encore prématuré, comment on envoi le résultat à un Arduino ?
Je veux dire j'ai déja envoyé des infos par port série sur l'USB pour allumer une LED (oui c'est un début !) mais les données de l'image je vois pas encore. On envoie la [Gemlist] ?
Vous l'aurez compris, je reviens vite
Merci encore à tous.
Hors ligne
Mais comment faire pour utiliser le shader si on veut par la suit envoyer les résultats de la décimation vers un arduino ? En CUDA à la limite ; pour continuer notre ultime conversation de jeudi dernier, Philippe.
Il y a sans doute des choses à faire avec gridflow. http://www.gridflow.ca
Hors ligne
Pour ce qui est de l'envoi à l'Arduino, c'est un protocole à écrire sans doute puisque Firmata n'est pas prévu pour faire ce genre de boulot. 40 x 40 ça fait un paquet de LED en tout (1600).
Une solution c'est de reprendre le code du LEDpong du Tetalab. Ca a été écrit pour une série de puces Max7313
http://tetalab.org/blog/13 et http://tetalab.org/blog/19
et le code ici : http://git.tetalab.org/index.php/p/ledp … ee/master/
Mais déjà avec 432 LED avec 16 niveaux pour chacune, le petit Arduino trime pour envoyer toutes les infos.
Le protocole qu'ils ont écrit est fait pour processing, mais ça doit pas être très compliqué à écrire pour Pd.
Dernière modification par pob (2012-04-28 02:27:02)
Hors ligne
Pas mal comme liens !
Par contre pour envoyer de PD à Arduino j'envoie directement de [gemlist] à [comport] ou il faut une conversion ou quelque chose de plus complexe ?
Hors ligne
Il faudra sans doute utiliser [pix_data] pour récupérer la valeur des pixels une fois la décimation faite comme te disait Olivier plus haut.
Hors ligne
ah oui je viens de comprendre le principe de [pix_data] ça m'a l'air pas mal oui. Bon ben c'est parfait ca me fait une bonne base de travail.
Je vous tiens au courant.
merci à tous.
Hors ligne
Booooon !
et bien ça m'a l'air d'aller dans le bon sens !
La première solution d'Olivier semble porter ses fruits je vais donc continuer dans ce sens.
Effectivement je pense utiliser [pix_data] via sa sortie valeur de nuance de gris.
Maintenant il ma faut comprendre l'utilisation des triggers pour prendre une mesure d'un pixel à la fois et aussi la logique des boucles dans puredata. Autant en programmation texte comme le C ou PHP je vois comment boucler mais j'ai pas encore compris la logique de PD !
si vous avez des exemples simples ca pourrait m'aider, mais je vais regarder la doc FLOSS.
ci joint : voila ou j'en suis.
Hors ligne
Une des manière de pondre des boucles avec Pd est la boite [repeat ]...
C'est elle que j'utilise pour lire l'image dans ma deuxième capture d'écran ci dessus...
Sans trop prendre de risque, ce bout de patch est exactement ce dont tu as besoin pour lire ton flux...
Pour faire simple, à chaque nouvelle image (donc 20 fois par seconde) il réalise 1600 fois ce qui suit...
En ajoutant un compteur, je m'assure que l'opération porte sur des pixels différents...
Bon courage...
Dernière modification par Olivier (2012-04-28 14:02:33)
Hors ligne
Merci Olivier.
Oui je vois bien que ta solution est exactement ce qu'il me faut. Ceci dit je suis plutot partisan de comprendre ce que je fais plutot que de copier bêtement. Mais justement je vais décortiquer ton patch pour voir comment tu as travailé la chose.
Merci encore
Hors ligne
Pages: 1 2