Discussion :

[trax44]

Bonjour,

je cherche a appliquer des opérations tel que des convolutions sur ma mémoire vidéo (tout ce qui s'affiche sur mon écran).

Je ne sais pas trop par ou commencer surtout que le binaire ne doit pas être spécifique (ou du moins le moins possible) a l'architecture : passer par l'api windows ou pas une librairie. Est ce que la SDL serait capable de faire ca par exemple (sans fenêtre apparente) ?


Cordialement

trax

--
sur un qwerty

[bacelar]

Vous ne pouvez pas accéder à la mémoire vidéo directement depuis un programme non kernel (drivers).
Vous devez passer par les API Windows ou par des bibliothèques qui utiliseront les API Windows.

[trax44]

Je vous remercie de votre réponse très rapide.

Je ne m'y connais plus beaucoup sous windows. Auriez-vous des conseils quant au choix des fonctions de l API ou d une librairie en particulier.

[bacelar]

Je ne connais pas la SDL mais en règle générale, plus les bibliothèques sont simples et multiplateforme plus les performances sont faibles.

Mais si vous n'avez pas de problème de performance, utilisez les bibliothèques que vous connaissez le mieux.

[trax44]

J'ai trouvé sur la doc de microsoft quelques fonctions qui font presque ce que je veux :
- lecture d'un pixel de l'écran
- sa modification.

Problème :
Comme prévu beaucoup trop lent et il faudrait que je puisse en quelque sorte interdire le rafraichissement. Il faudrait que windows ecrivent dans un buffer qui ne s'affiche pas, que je puisse copier ce buffer, le modifier et l'afficher quand les calculs sont finis.

Disposant de deux sorties sur ma carte graphique est ce qu il serait possible de garder l affichage normale sur la première interface et d'utiliser la deuxieme pour envoyer mes modifications ?

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
    COLORREF color;
    HDC hDC;

    int i,j;
    char t;

    hDC = GetDC(NULL);
    if (hDC == NULL)
        return CLR_INVALID;


    for (i = 0 ; i < WIDTH ; i++){
        for (j = 0 ; j < HEIGHT ; j++){
            color = GetPixel(hDC, i, j);
            SetPixel(hDC, j, i, -color);
        }
    }
    ReleaseDC(GetDesktopWindow(), hDC);

[bacelar]

SetPixel a un lourd passif de non-performance.
Je pensais même que les autres approchent l'auraient cachés sous Google.
Faut croire que non, la simplicité s'utilisation doit en être la cause.

Vos explications semblent montrer que vous n'avez pas besoin d'accéder à la mémoire vidéo mais afficher des données ?

Faites-vous un "post-traitement" de l'affichage du bureau, nécessitant effectivement un accès à l'affichage du bureau, ou faites vous simplement de l'affichage ?

Le mécanisme que vous décrivez a un nom, c'est le double-buffering, et s'il à un nom, c'est que des développeurs l'ont implémenté.
C'est le cas dans toutes les librairies graphiques que j'ai utilisé. Donc je pense que si vous en utilisez déjà une, elle le gère.

Le truc, c'est que la manière de faire est vraiment fonction de la librairie graphique.

Par exemple, avec DirectX, on utilise généralement des textures dynamiques.

http://msdn.microsoft.com/en-us/libr...namic_Textures

[trax44]

re,

a la base de m'on projet on m'a demandé de créer un programme en verilog pour un module qui se mettrait entre la sortie de la carte graphique et l'écran. Je suis persuadé que le faire en logiciel serait plus simple.

Ce que je dois donc faire c'est appliquer mes algorithmes de traitement d'images sur tout ce qui s'affiche à l'écran, et me positionner après les dernières modifications de ce cher windows.

Oui c'est en sorte du double buffering, j'en connais le principe, mais le problèmes est que jusqu'à présent, quand j'utilisais ce genre de technique je maitrisais le buffer d'entrer et de sortie.

Dans le cas présent je ne sais pas comment dissocier les deux : dire a windows d'écrire dans le premier et de n'afficher le deuxième.

[bacelar]

Ca commence à être plus clair mais je pense qu'il y a un petit problème.

ce cher windows

n'est pas le dernier à modifier l'image. Et loin s'en faut.

Cela fait bien longtemps que le signal en sortie du PC n'est pas le produit de la modulation analogique d'une zone de la mémoire centrale par un composant sans intelligence.
Je crois que c'est depuis l'avènement des cartes graphiques 2D accélérant le GDI.

C'est donc le carte graphique qui maintient les informations nécessaire à la génération du signal vidéo, maintenant de plus en plus numérique, en sortie du PC.

Je ne connais pas précisément la nature du signal vidéo (bureau Windows, application plein écran, avec DirectX ou non). Mais si le traitement doit s'appliquer à tous ces types et aussi sur des OS différents de Windows, je pense que ces personnes ont fait le bon choix.

Si vous restez sous Windows, je vois un certain nombre de solution en fonction de vos objectifs.

Si vous voulez absolument accéder à une "mémoire vidéo" reconstituée depuis la carte graphique, vous pouvez utiliser des fonctionnalités comme celles de DirectX pour mettre les textures dynamiques en mémoire système et faire un rendu d'un simple billboard. Mais c'est pour une application développée maison, pas le système.

Vous pouvez toujours essayer de faire un driver vidéo GDI transparent, mais ce n’est pas trivial et vous ne verrez que les fonctions GDI.

Vous pouvez aussi implémenter des drivers DirectX ou OpenGL transparent, mais c'est encore plus de bouleau que le GDI et encore moins trivial.

Moi, je vous conseillerais de vous intégrer dans le flux strandard des traitements faits par la carte graphique via l'implémentation de Pixel Shader DirectX ou OpenGL.

P.S. : le signal vidéo en entrée devrait être en VGA, DVI HDMI ? VGA est analogique, me semble-t-il.

[trax44]

En regardant quelques tutoriaux un peu partout j'ai essaye tant bien que mal d'ecrire cela. C'est a l'interieur du callback d'une fenetre qui recoit tout les evenement de l'ecran (dans le client real vnc plus exactement).

Normalement ca ne devraint rien changer mais j'obtiens une fenetre toute noire. Je n'ai aucun message d'erreur donc difficile a debugger.

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
40
41
	  BITMAPINFO bitmapinfo;

	  memset(&bitmapinfo,0,sizeof(BITMAPINFO));
	  bitmapinfo.bmiHeader.biSize=sizeof(BITMAPINFOHEADER);
	  bitmapinfo.bmiHeader.biWidth=bm.bmWidth;
	  bitmapinfo.bmiHeader.biHeight=bm.bmHeight;
	  bitmapinfo.bmiHeader.biPlanes=1;
	  bitmapinfo.bmiHeader.biBitCount=32;


	  UINT *buff;
	  myBMP2 = CreateDIBSection(paintDC, 
				    (BITMAPINFO *)&bitmapinfo, 
				    DIB_RGB_COLORS,
				    (void **)&buff, 
				    NULL, 0);
	  GetDIBits (paintDC,
		     myBMP2,
		     0, bm.bmHeight,
		     buff,
		     &bitmapinfo,
		     DIB_RGB_COLORS
		     );

	  SetDIBits (paintDC,
		     myBMP2,
		     0, bm.bmHeight,
		     buff,
		     &bitmapinfo,
		     DIB_RGB_COLORS
		     );

	  HDC hdcMem = CreateCompatibleDC(paintDC);



	  SelectObject(hdcMem, myBMP2);

 	  if (!BitBlt(paintDC, pr.tl.x, pr.tl.y, pr.width(), pr.height(),
		      hdcMem, buf_pos.x, buf_pos.y, SRCCOPY))

[bacelar]

Il manque pas mal d'info dans votre code.

Pouvez-vous poster en pièces jointe une version minimaliste de vos sources ?

[trax44]

http://pastebin.ca/1904982

Le probleme est toujours le meme : je cherche a acceder aux pixels de mon images. Dans le cas present j'essaye de d'acceder au buffer via les methodes DIB.

Resultat : ecran noir.

Les valeurs de retours de GetDIBits et SetDIBits semblent etre correcte (nombre de ligne de la partie modifiee)

[bacelar]

Il y a beaucoup de variables ou membres non défini dans le code posté.
C'est assez difficile de voir les problèmes quand on ne sait pas comment des valeurs sont manipulées.
Le début du code me semble correct mais la fin du code utilise des valeurs arbitraires en pagaille.

Pouvez-vous posté un code minimal "complet" pour voir le problème ?

[Mat.M]

Je ne sais pas trop par ou commencer surtout que le binaire ne doit pas être spécifique (ou du moins le moins possible) a l'architecture : passer par l'api windows ou pas une librairie.

si tu veux vraiment des performances il faut passer par Direct X et le langage HLSL pour faire de la programmation GPU ...
c'est ce que l'on fait dans ma boite...
là tu obtiendras des performances optimales; SDL c'est vraiment trop lent comme API même le GDI est parfois plus performant
ce sera même plus souple voire facile qu'avec SetDIBits et GetDIBits qui sont des fonctions assez complexes à utiliser parce que tu dois jouer avec le paramêtrage GDI

Resultat : ecran noir.

Les valeurs de retours de GetDIBits et SetDIBits semblent etre correcte (nombre de ligne de la partie modifiee)

dans le code donné tu ne fais aucune opération ;
Il faut accéder aux octets du tableau buff pour dessiner et afficher le résultat avec SetDIBits()

Code :

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

1
2
3
if (!BitBlt(paintDC, pr.tl.x, pr.tl.y, pr.width(), pr.height(),
		      hdcMem, buf_pos.x, buf_pos.y, SRCCOPY))

Il n'est pas utile dans ce cas-là de faire un HDC en mémoire parce que justemeent SetDIBits permet de dessiner à l'écran...
sauf si tu veux gérer un système de calques en quelque sorte.


Prendre pour exemple les démos de AngelScript
http://www.angelcode.com/angelscript/downloads.asp
l'auteur utilise GetDIBits et SetDIBits pour dessiner