Discussion :

[Franck SORIANO]

Pour bien comprendre, dans le 2ème appel à GetImageData, on lui passe "@LBuffer[0]", ça veut dire quoi concrètement ?

Ca veut dire que tu passes en paramètre l'adresse du premier élément du tableau.

Aussi la violation d'accès sur le move, que se passe t il exactement dans cette instruction ?

Le move sert à recopier un bloc de données vers un autre.
Dans mon exemple, on recopie les données de LBuffer[n] dans la ligne n° i du bitmap.

ScanLine[i] retourne un pointeur sur les données de la ligne i.
Si le bitmap est au format 24 bits, ca veut dire que chaque pixel est un triplet (Rouge, Vert, Bleu) donc 3 octets par pixels. C'est pour ça qu'on fait la copie sur une longueur de nWidth*3.

Remarque normalement, on devrait aussi avoir :
nBufferSize = nWidth*nHeight*3.

Si nBufferSize est plus petit, tu auras un acces violation lors des Move. Mais dans ce cas, ça veut dire que ton image n'est pas au format RGB24.

Donc pour commencer, tu peux regarder quels sont les valeurs de nBufferSize, nWidth et nHeight après l'appel à GetImageData.
Et surtout regarde la valeur de nBufferSize/(nWidth*nHeight), ça te donnera la taille d'un pixel en octets, ce qui permet pratiquement de déterminer le format de l'image.

Autre chose également, regarde à quelle ligne du bitmap tu obtiens l'erreur (pour quel i et pour quel n).

[KRis]

Je vois, tout s'éclaircit petit à petit.

Je viens de me rendre compte que le nWidth et nHeight ne sont pas les dimensions en pixels de l'image mais :

o_nPhysicalWidth Physical width of this image in nm
o_nPhysicalHeight Physical of this image in nm

hors c'est bien la dimension en pixels qu'il faut pour ton calcul je pense :

nBufferSize = nWidth*nHeight*3

j'avais un bufferSize à 750 000, un nWidth à 228 000 et nHeight à 227 000...
évidemment le BufferSize avec ces valeurs était trop petit, d'où la violation d'accès comme tu disais.

En fait je définis avant l'appel à GetImageData la résolution en pixels de l'image désiré par une autre fonction "SetCameraResolution(500,500)".
(du 500 par 500 pixels !)

avec ces valeurs, cela fonctionne parfaitement ! (je te dois un grand merci Franck)

petite question :

Si le bitmap est au format 24 bits, ca veut dire que chaque pixel est un triplet (Rouge, Vert, Bleu) donc 3 octets par pixels. C'est pour ça qu'on fait la copie sur une longueur de nWidth*3.

Si je travaille avec du 16 ou 32 bits, comment remanier l'algorithme de parcours et scan du buffer ?

[Franck SORIANO]

Si je travaille avec du 16 ou 32 bits, comment remanier l'algorithme de parcours et scan du buffer ?

C'est simple, en RGB24 tu as 3 octets par pixel.
En 16 bits (RGB16 ou RGB15) tu as 2 octets par pixel.
En 32 bits (ARGB (j'ai un doute sur le nom)) tu as 4 octets par pixel.

Donc en fait tu as :

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
 
var
  TailleLigne : integer; // Taille d'une ligne en octets
  Largeur : integer; // Largeur de l'image en pixels.
  Hauteur : integer; // Hauteur de l'image en pixels.
  pf : TPixelFormat; // Format de l'image
  LBuffer : array of byte;
  bmp : TBitmap;
  n : integer;
  i : integer;
begin
  ... // Initialiser les valeurs : Largeur, Hauteur, pf et LBuffer
 
  case pf of
  pf15bit, pf16bit:
    TailleLigne := Largeur*2;
  pf24bit:
    TailleLigne := Largeur*3;
  pf32bit:
    TailleLigne := Largeur*4;
  else Raise Exception.Create('Format non géré !');
  end;
 
  bmp := TBitmap.Create;
  bmp.Width := Largeur;
  bmp.Height := Hauteur;
  bmp.PixelFormat := pf;
  n := 0;
  for i := 0 to Hauteur-1 do
  begin
    move(LBuffer[n], bmp.ScanLine[i]^, TailleLigne);
    inc(n, TailleLigne);
  end;
end;

[KRis]

Encore merci Franck pour m'avoir aider à y voir plus clair et à démêler beaucoup de noeuds.
Je tagge ce post en résolu !