Discussion :

[supernewbienoob]

Bonjour, je voudrais apprendre à manipuler les pixels d'une image avec la lib windows. J'ai cherché de la doc mais c'est très compliqué...

voilà à quoi ressemble mon code pour l'instant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
		case WM_PAINT:
		hdc = BeginPaint(hWnd, &ps);
 
 
 
		// TODO: ajoutez ici le code de dessin...
 
		int i, j;
 
		for ( j=0 ; j<480 ; j++ ) {
			for ( i=0 ; i<640 ; i++ ) {
				SetPixelV( hdc , i , j , COLORREF RGB(j,i,i&j) );
			}
		}
 
 
		EndPaint(hWnd, &ps);
		break;

C'est horriblement lent... il faut que j'utilise autre chose



[edit] je n'ai peut-être pas posté dans la bonne section

[supernewbienoob]

il parait qu'il faut utiliser un "GDI" mais j'ai cherché de la doc et j'ai rien compris ça m'a l'air compliqué

[Ange_blond]

Bonjour,

BeginPaint est une fonction de l'API windows... donc tu utilise dejà des libs techniquement...

Que l'interet à refuser d'utiliser les libs classiques ?

Edit : tu as donc choisis la lib windows... la question devient donc : pourquoi celle ci ? l'API windows est rarement réputée pour sa facilité d'utilisation ?

[supernewbienoob]

ben je refuse pas d'utiliser le truc GDI mais je cherche de l'aide car j'y comprends rien

[supernewbienoob]

mais ce que je cherche à faire c'est simple c'est juste définir une image de a*b pixels et changer la couleur du pixel (x,y)

[supernewbienoob]

j'ai trouvé un tuto: http://www.winprog.org/tutorial/bitmaps.html

mais j'y comprends rien...

[oxyde356]

Commence pas par l'API Windows sinon tu vas vite abandonner, c'est une vraie usine à gaz et c'est très vieux et ça à mal évoluer, des rustines par ci par là. Donne plus de détails tu veux faire un traitement sur un image ok et après c'est dans quel but, l'afficher ? la sauvegarder dans un fichier ? es-tu sûr d'avoir vraiment besoin d'une api qui va gérer le fenêtrage, les évènements ou tout ce que tu as besoin c'est une application console tu vas lui renseigner le nom d'un fichier ça va faire le traitement dessus et ton application va se fermer ?

[Mat.M]

j'ai trouvé un tuto: http://www.winprog.org/tutorial/bitmaps.html

mais j'y comprends rien...

non c'est pas la bonne méthode qui est donnée
L'exemple donné sur winprog charge une bitmap liée en ressource dans l'exe puis l'envoie dans un HDC en mémoire
Après on affiche la bitmap avec BitBlt

Il faut utiliser CreateDIBSection qui te permet de gérer un tampon hauteur * largeur.
Dans ce tampon tu peux accéder pixel par pixel ce qui te permet de dessiner et ensuite faire un BitBlt
Si j'ai un instant j'essaierai de te faire un exemple..

[Mat.M]

Commence pas par l'API Windows sinon tu vas vite abandonner, c'est une vraie usine à gaz et c'est très vieux et ça à mal évoluer, des rustines par ci par là.

eehhh l'API Windows
1-c'est pas vieux et encore moins cela évolue mal c'est la base du développement sous Windows.Même .NET est basé dessus
2-à l'heure qu'il est je programme toujours avec en milieu professionel et aussi pour projets personnels.

C'est peut-être une usine à gaz mais sans API WIndows .NET et autres ne peuvent même pas fonctionner sous Windows...

[oxyde356]

Ce n'est pas parce que c'est la base que c'est une bonne idée de l'utiliser quand on ne sait pas encore manipuler les pixels d'une image. Et ce n'est pas non plus parce que ça sert de base à un framework que c'est une référence indémodable. Vu que supernewbienoob à l'air d'être en difficulté je lui conseil plutôt d'utiliser une librairie plut haut niveau qui sera beaucoup plus facile à utiliser, mais pour ça il faudrait qu'il précise ses contraintes.

[moldavi]

Bonjour.

C'est horriblement lent... il faut que j'utilise autre chose

Autre chose, ce sera DirectX, voir WPF dont le moteur est basé sur DirectX.

La manipulation optimisée de pixels, c'est le job des GPU. Mais comme le dit oxyde356 précises tes contraintes.

[moldavi]

Commence pas par l'API Windows sinon tu vas vite abandonner, c'est une vraie usine à gaz

Effectivement, depuis le temps que ça existe, c'est une usine à gaz. Comme pour toutes les API "grosse en volume", aurais-je envie de dire. Elle n'est pas plus compliquée à utiliser qu'une autre API.

c'est très vieux

Oui c'est vieux... Ca existe depuis longtemps. Mais si c'est comme le vin, plus c'est vieux, plus c'est ... mature.

et ça à mal évoluer

Il faudra donner des preuves de cette phrase, parce que je pense que c'est écrit dans la précipitation.

Ici le blog http://blogs.msdn.com/b/windowssdk/

Dernière version en date la 7.1 (juillet 2010). Pour une API qui évolue mal, c'est plutôt le contraire.

Je ne cherche pas à défendre cette API. Je comprends ton point de vue de dire qu'utiliser une API plus haut niveau est intéressante. Mais je ne peux pas te laisser parler de cette API de cette façon.

[oxyde356]

Non non, quand je dis que ça a mal évolué je parle de l'api en elle même pas de ces "extentions" qui s'en servent à merveille, et quand je dis mal évolué je parle de la qualité pas de la quantité, oui grâce à cet API on peut faire tout et n'importe quoi, mais le code est a vomir. Un débutant comme supernewbienoob ne peut pas et ne devrait vraiment pas commencer par cette API. S'il veut faire un traitement simple et l'afficher dans une fenêtre il vaut 100x mieux commencer par du Qt, du wxWidget qui sont 100x plus simple et qui j'imagine répondront bien mieux à son attente. Après quand il sera un peu plus rodé il pourra passer au Windows SDK s'il veut faire des choses plus complètent spécifiquement sur windows. Mais là sortir l'API Windows en C (car c'est bien de ça que l'on parle), il va vraiment avoir du mal à comprendre tout ça juste pour traiter des pixels et les afficher, les gars arrêtez l'élitisme vous allez nous le décourager ^^

PS: pour ton histoire de vin moldavi, dis toi qu'il a commencé a avoir un gout de bouchon il y a quelques années déjà

[Emmanuel Deloget]

Non non, quand je dis que ça a mal évolué je parle de l'api en elle même pas de ces "extentions" qui s'en servent à merveille, et quand je dis mal évolué je parle de la qualité pas de la quantité, oui grâce à cet API on peut faire tout et n'importe quoi, mais le code est a vomir. Un débutant comme supernewbienoob ne peut pas et ne devrait vraiment pas commencer par cette API. S'il veut faire un traitement simple et l'afficher dans une fenêtre il vaut 100x mieux commencer par du Qt, du wxWidget qui sont 100x plus simple et qui j'imagine répondront bien mieux à son attente. Après quand il sera un peu plus rodé il pourra passer au Windows SDK s'il veut faire des choses plus complètent spécifiquement sur windows. Mais là sortir l'API Windows en C (car c'est bien de ça que l'on parle), il va vraiment avoir du mal à comprendre tout ça juste pour traiter des pixels et les afficher, les gars arrêtez l'élitisme vous allez nous le décourager ^^

PS: pour ton histoire de vin moldavi, dis toi qu'il a commencé a avoir un gout de bouchon il y a quelques années déjà

Une guerre se prépare ! Ceux qui sont contre l'API Windows, et ceux qui sont pour ! J'adore le principe ! Puis-je y participer ?

Plus sérieusement, et pour répondre à la question de l'utilisateur : GDI, c'est la partie de l'API Windows qui gère le graphisme sous Windows (y compris le dessin des fenêtres, etc). Ca veut dire Graphic Device Interface. On peut se servir d'une partie de ses fonctions pour manipuler des images.

Dans l'API offerte par GDI, il existe deux types d'images : les images dites DDB (Device Dependant Bitmap), dont les caractéristiques sont fixées par le mode d'affichage en cours (nombre de couleurs, principalement). Et puis il y a les images dites DIB pour Device Independant Bitmap, dont les caractéristiques ne sont en rien liées à l'affichage en cours, mais au contraire uniquement liées à ce que le programmeur a souhaité faire avec.

Les DDB ne peuvent pas être manipulées directement : on est obligé de passer par les API de la GDI pour les créer, les modifier, les traiter, etc. Histoire de simplifier, disons qu'elles sont gérées entièrement par le système, ce qui lui permet de les garder par exemple dans un format optimisé pour un affichage rapide. Une DDB est référencée par un handle sur un bitmap - un HBITMAP.

Les DIB ne sont pas à proprement parlé gérées via les API de la GDI. Ce que fourni l'API, c'est un moyen de transférer une DIB vers une DDB (StretchDIBits et consorts), ou le moyen de transférer une DIB dans un contexte graphique mémoire (un faux contexte graphique, qui prétends être un contexte d'affichage mais qui en fait travaille uniquement sur une zone mémoire; on les appelle des MemDC, pour memory device context).

Pour créer une DIB, il suffit juste de créer une zone mémoire de taille suffisante pour stocker tous les pixels de l'image. Il faut juste faire attention à un point particulier : dès lors qu'on souhaite transférer une DIB vers un MemDC ou vers une DDB, le système va demander que certaines informations très particulières soient respectées :

1) le padding. Le nombre de bytes contenus dans une ligne d'une DIB doit être divisible par 4. Je ne parle pas d'un nombre de pixel, mais bien d'un nombre de bytes. Ca permet au système d'affichage de ne pas faire d'accès non aligné.

2) dans les modes sans palette, chaque pixel est représenté par un tripplet de couleur au format BGR (bleu, puis vert, puis rouge), et non pas le classique RGB qu'on trouve ailleurs.

3) la dernière ligne de la DIB est en fait celle qui est affichée en haut (pour des raisons historiques; les premières version de Windows affichait les images à partir du bas, et montait vers le haut. Du coup, la première ligne affichée était en bas, la suivante un pixel au dessus, etc).

Du coup, on va réviser des vieilles formules et les vieilles structures:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
struct pixel
{
   unsigned char b, g, r;
};
 
struct image
{
  unsigned int width;
  unsigned int height;
  pixel* data;
};
 
// without padding...
unsigned int real_line_size(unsigned int width, unsigned int pixel_size)
{
   return (width * pixel_size);
}
 
// with padding...
unsigned int system_line_size(unsigned int width, unsigned int pixel_size)
{
   return (real_line_size(width, pixel_size) + 4) & (~3);
}
 
pixel* create_dib_data(unsigned int width, unsigned int height)
{
   unsigned int byte_count = system_line_size(width, sizeof(pixel)) * height;
   return (pixel*)new char[byte_count];
}
 
image* create_image(unsigned int width, unsigned int height)
{
  image* img = new image;
  image->width = width;
  image->height = height;
  image->data = create_dib_data(width, height);
  return image;
}

Ensuite, il nous faut accéder aux données. Si on souhaite y accéder de manière discrète (on connait x, y, et on souhaite juste accéder à ce point là), ce n'est guère difficile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
// on ne peut pas y accéder aisément, à cause du padding :(
pixel* get_pixel(image* img, unsigned int x, unsigned int y)
{
  unsigned int real_y = img->height - y;
  unsigned int line_offset = real_y * system_line_size(img->width);
  pixel* p_line = (pixel*)(((char*)img->data) + line_offset);
  return p_line + x;
}

Mais le plus intéressant, c'est quand même de parcourir les données, ligne par ligne, pixel par pixel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
pixel* get_line(image* img, unsigned int y)
{
  unsigned int real_y = img->height - y;
  unsigned int line_offset = real_y * system_line_size(img->width);
  return (pixel*)(((char*)img->data) + line_offset);
}

Qui s'utilise ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
for (unsigned int y=0; y<img->height; ++y)
{
  pixel* line = get_line(img, y);
  for (unsigned int x=0; x<img->width; ++x)
  {
    pixel* p = line + x;
  }
}

Ce code peut bien évidemment être optimisé dans tous les sens.

Une fois qu'on a fini de jouer avec la DIB, on peut soit directement afficher le résultat (StretchDIBits, SetDIBitsToDevice), soit créer une DDB à partir de cette DIB (CreateDIBitmap). A chaque fois, il faudra préciser un ensemble d'information sur l'image, sous la forme d'une structure BITMAPINFO. Mais ça, c'est une autre histoire, et c'est clairement facile de trouver ces informations sur internet (maintenant que j'ai donné les mots-clefs )

[Mat.M]

Ce code peut bien évidemment être optimisé dans tous les sens.

c'est très bien d'avoir donné du code mais il est inutilisable sous Windows ; il faut comme tu l'écris ensuite utiliser les API du GDI..

[Emmanuel Deloget]

c'est très bien d'avoir donné du code mais il est inutilisable sous Windows ; il faut comme tu l'écris ensuite utiliser les API du GDI..

Il est utilisable, mais en lui même, il ne fera rien de spécial. Ceci dit, le principe, c'est quand même de manipuler une image, donc j'ai fournit le code permettant de créer et d'accéder aux données d'une DIB. Ensuite, ce qu'on fait de la DIB, ça ne me regarde pas

Et j'ai quand même donné le nom des fonctions à utiliser pour s'en sortir - ce n'est pas comme si l'OP avait des problèmes de compréhension de l'API windows, vu qu'il s'en sert déjà.

[oxyde356]

Arrêtons de polémiquer je crois que l'auteur du sujet est partie et sans les contraintes on parle dans le vide ça se trouve on est complètement out

[Emmanuel Deloget]

Arrêtons de polémiquer je crois que l'auteur du sujet est partie et sans les contraintes on parle dans le vide ça se trouve on est complètement out

Le jour ou Mat.M et moi-même polémiquerons n'est pas encore arrivé, mon cher

Il levait une objection tout à fait raisonnable. Quand au fait que l'auteur du sujet soit parti : ce n'est pas parce qu'il ne poste pas qu'il ne lit pas. Et d'autres peuvent avoir le même problème.

Voyon, voyons, ou est ta foi ?

[Mat.M]

Arrêtons de polémiquer je crois que l'auteur du sujet est partie et sans les contraintes on parle dans le vide ça se trouve on est complètement out

non il n'y a pas de polémiques ,l'informatique c'est pas comme les débats politiques ,l'informatique c'est trouver des solutions concrètes.

En quelques secondes j'ai trouvé cela dans le MSDN pour éviter l'emploi de SetPixel

http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx


Il faut créer une "bitmap info"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// setup bitmap info  
    // set the bitmap width and height to 60% of the width and height of each of the three horizontal areas. Later on, the blending will occur in the center of each of the three areas. 
    bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
    bmi.bmiHeader.biWidth = ulBitmapWidth = ulWindowWidth - (ulWindowWidth/5)*2;
    bmi.bmiHeader.biHeight = ulBitmapHeight = ulWindowHeight - (ulWindowHeight/5)*2;
    bmi.bmiHeader.biPlanes = 1;
    bmi.bmiHeader.biBitCount = 32;         // four 8-bit components 
    bmi.bmiHeader.biCompression = BI_RGB;
    bmi.bmiHeader.biSizeImage = ulBitmapWidth * ulBitmapHeight * 4;
 
    // create our DIB section and select the bitmap into the dc 
    hbitmap = CreateDIBSection(hdc, &bmi, DIB_RGB_COLORS, &pvBits, NULL, 0x0);
    SelectObject(hdc, hbitmap);

et appeler CreateDIBSection.
Je conseille de fixer bmi.bmiHeader.biBitCount à 24 plutot que 32

Pour dessiner il suffit d'accéder le tableau VOID *pvBits;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
for (y = 0; y < ulBitmapHeight; y++)
        for (x = 0; x < ulBitmapWidth; x++)
                          ((UINT32 *)pvBits)[x + y * ulBitmapWidth] = 0x00ff0000;

Après il suffit d'appeler StretchDIBBits et utiliser pvBits

[supernewbienoob]

Merci à tous pour votre aide

Merci aussi à Mat pour son trait d'humour qui m'a bien fait rire

non il n'y a pas de polémiques ,l'informatique c'est pas comme les débats politiques ,l'informatique c'est trouver des solutions concrètes.

Bon hé bien je vais essayer avec le code que m'a filé Mat pour commencer (pas tout de suite car j'ai pas mal de travail pour l'instant).

Si vraiment j'y arrive pas j'essayerai la SDL on m'a dit que c'était plus simple, mais j'aurais préféré m'en sortir sans passer par des trucs hardware et des libs à télécharger... et puis ça peut me servir d'apprendre un peu la lib windows si je veux me faire des ptit widgets.

Des contraintes en fait j'en ai pas. Je veux juste apprendre à bidouiller les pixels, et donc il faut les afficher.