Salut,
je débute en C++ et je voudrais faire de l'analyse ultra basique d'images et de video en C++ et du graphisme simple en 2D, animé
 
 
en fait, je connais bien la librairie graphique de Java que j'utilise en gros comme ça :
 
graphics.fillRect(10,10,20,20);
graphics.setColor(Color.red);
graphics.drawOval(..);
 
le tout en boucle sur une fenêtre que je rafraîchis, et j'ai des animations.
 
et je cherche dans le même genre en C++ (sans 3D donc) car j'aimerais combiner du graphisme animé 2D avec de la video temps réel (par exemple d'une webcam).
j'ai lu que DirectShow.
 
en fait ma question c'est : est-ce qu'il existe un truc plus simple (même si moins puissant) pour combiner ce genre de trucs que directX  ?
 
il vaut mieux faire :
 
acquisition directShow -> traitement -> affichage directX  
acquisition directShow -> traitement -> affichage autre  
acquisition autre -> traitement -> affichage autre
 
 
voilà.

tu peux regarder ca :
http://www.codeproject.com/audio/featuretracking.asp
pour la partie capture.

ça dépend de ce que tu sais déja faire
 
Est-ce que tu connais la programmation graphique bas niveau (ie comment est fait un framebuffer)? Faire du graphisme procédural (ie coder toi meme les FillRect et consorts)?
Est-ce que tu sais controler un codec (d'un point de vue programmation, pas utilisation d'un frontend genre VFW)?
Est-ce que tu sais blitter un buffer?  
 

SquiZZ > merci ça a l'air super
 
retrox > pour ce qui est des codecs, non, j'y connais rien (j'utilisais des trucs tout faits en java)
 
pour le graphisme bas niveau, en fait ce que je voudrais utiliser est très simple
 
j'ai déjà fait un peu de graphisme en C pur, en enregistrant directement les images sur le disque et manipuler un grand tableau de 800*600 pixels me suffirait à la limite
tout ce que j'aimerais c'est pouvoir le faire en double buffering en C++
 
j'ai déjà fait du double buffering avec wxWidgets remarque, mais je crois pas que pour l'animation, c'est ce qu'il y ait de mieux (même si je pense pas avoir besoin d'une accélération matérielle)
 
 
 
note : voilà je genre de trucs que j'ai fait en C pur, un truc pixel par pixel me suffirait
 


 
 
remarque : en fait ce programme prennait vachement beaucoup de ram, parce que chaque pixel est un objet qui contient 3 double R, G, B (je convertissais en char à la fin)

Hyperplan de quaternions ? Attracteur étrange? C'est zouli en tout cas.
 

Ca va dépendre de la librairie utilisée pour afficher ton buffer.  
GDI (Win32/MFC) : double-buffering à la main
DirectX (DirectDraw) : flipping chain
OpenGL : pixel format avec double-buffering
 
Fondamentalement, ça change pas grand chose.  
Cela dit, pourquoi se priver de l'accélération matérielle? C'est pas plus compliqué que de se farcir une API soft (comme GDI), et c'est beaucoup plus puissant (surtout si tu veux faire du compositing). Enfin bon ça dépend de ton but. Si c'est pour apprendre, pourquoi pas tout faire en soft. Si c'est pour aboutir plus rapidement au résultat, autant utiliser le matériel et les librairies qui l'exposent.
 
Sinon c'est clair, c'est pas une super idée un objet par pixel ;-) Faut travailler avec des tableaux, unidimensionnels de préférence (à toi de faire l'adressage proprement (attention à l'alignement)).

merci !
mais on (je sais pas ce que ça vaut) m'a dit que openGL de toutes façons, ils calculait de la 3d tout le temps, ce qui me semble un peu dommage
 
pour directX, en fait, j'ai installé le sdk 9, compilé un hello world (en fait le teapot en  3D ) avec devC++, mais j'avoue que je suis cassé par le nombre de lignes du fichier principal (1700) et j'ai comme l'impression que c'est un truc pas à la même mesure de ce dont j'ai besoin.
 
en même temps, c'est ptet parce que c'est de la 3D, je vais chercher des exemples de directDraw "pur"
 
 
l'exemple posté par SquiZZ reçoit et traite les images en MFC (là aussi j'y connais rien) et j'me dis que c'est ptet plus adapté de garder la même techno pour l'acquisition et l'affichage, c'est pour ça que je cherchais un bon compromis
 
 
sinon, les images c'est effectivement des attracteurs étranges
plus d'infos là : http://www.imagenese.net/attractors

Je te conseille de jeter un coup d'oeil à libSDL ( http://libsdl.org/ )
Il y a tout ce qu'il faut pour faire des manipulations pixel par pixel et aussi un module pour la decompression video mpeg

Pour OpenGL ce n'est pas tout à fait exact. Une partie de l'API est consacrée à la manipulation d'image (courament appelé pixel path). Par contre la partie à base de primitives (celle dont on parle en général) repose effectivement sur un pipeline 3D classique, meme pour de la 2D (et la 1D). Mais ce n'est en rien un handicap, ni en terme de performance, ni en terme de foncionnalité.
 
Pour ce qui est de DirectX, oui c'est une grosse machine, et le premier pas est le plus dur à faire. En particulier le code d'initialisation est fastidieux, mais c'est pareil avec toutes les APIs (du moins sans utilisation de toolkit approprié). Une fois que tu as pigé les grands principes de design de l'API, c'est du tout cuit
DirectDraw si je me souviens bien n'est plus modifié depuis DX7, et pour cause, c'est ce qu'il y a de plus bas niveau. En gros, il n'y a pas grand chose, juste de quoi allouer des surfaces, les permutter, les afficher (avec synchro verticale éventuellement)... Donc bon, une fois que tout ça est bien défini et implémenté, y a pas besoin d'y toucher d'une version à l'autre.
 
SDL j'attendais que quelqu'un le mentionne. Je connais pas du tout. Il parait que c'est bien
 
Si tu veux pas te prendre la tete, trouve une petite lib pour l'acquisition video, fais ton traitement, et utilise une API simple pour affichage (je veux dire : qui ne nécessite pas 500 lignes d'initialisation).
Si tu veux faire moderne, je te conseillerais DirectShow + Direct3D (meme si c'est pas 3D, c'est pas grave).

merci de tes conseils