Discussion :

[tourlourou]

Bonsoir,

J'obtiens une différence à l'exécution du même code source sous Lazarus Win7 32 bits et CodeTyphon (Lazarus 64) Ubuntu.

J'obtiens sous Win7 l'affichage de l'image couleur attendue, mais sous Ubuntu une image reconnaissable, grise, avec des rayures colorées verticales...

Pour éliminer certaines causes, j'ai sauvé dans un fichier le tableau RGB (PBA dans le code ci-dessous) que je passe en ScanLine à un TLazIntfImage, copié vers un BitMap qui est assigné à un TImage pour l'affichage (ouf !)

Et le fichier correct sous Win7 donne la même image grise sous Ubuntu que celle obtenue par le traitement normal !

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
  tms:=TMemoryStream.Create;
  tms.Write(PBA[0], FWidth*FHeight*3); // PBA = TByteArray : tableau de RGB style BitMap
  tms.SaveToFile('testbmp.bin');
  tms.Clear;
  tms.LoadFromFile('testbmp.bin');
  FillChar(PBA[0], FWidth*FHeight*3, 0);
  tms.Read(PBA[0], FWidth*FHeight*3);
  tms.Free;
  // passage au Bitmap de travail
  with ScanlineImage // TLazIntfImage
  do begin
    BeginUpdate;
      for yy:=0 to FHeight-1 // PRT = TRGBTripleArray absolute PBA
      do Move( PRT[yy*FWidth], TPRT(GetDataLineStart(yy))[0], ScanlineSize );
    EndUpdate;
  end;
  // puis à celui interne à passer
  FBitmap.LoadFromIntfImage(ScanlineImage);   
  // puis Image1.Picture.Assign(FBitmap);

Je ne sais plus où donner de la tête !

Merci pour vos pistes.

[tourlourou]

Je viens de faire le test inverse : le fichier tableau généré sous Ubuntu est bien affiché comme attendu sous Win7.

Il y a donc une différence de comportement entre les 2 versions de Lazarus ou les 2 environnements dans le passage au TLazIntfImage ou au BitMap.

Création du TLazIntfImage :

Code :

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

1
2
3
4
5
6
7
8
  ScanlineImage:=TLazIntfImage.Create(0, 0, [riqfRGB]);
  with ScanlineImage
  do begin
    BeginUpdate;
      SetSize(FWidth, FHeight);
      CreateData;
    EndUpdate; 
  end;

D'un côté, je suis content que mon code qui précède cette étape soit portable

[Paul TOTH]

comment est déclaré PRT ? n'y a-t-il pas une différence 32/64 bits ?

[tourlourou]

Je ne crois pas :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
type
  // pixel RGB ou YUV
  TYUV3=packed record
  case Boolean of
    True : (Blue, Green, Red: Byte); // = TRGBTriple
    False: (Y, U, V: Byte);
  end;
 
  // ligne de pixels
  TPRT=array of TYUV3;    
 
var
  PBA: PByteArray;
  PRT: TPRT absolute PBA; // pour traiter le buffer par octet, RGBTriple, ou YUV

[tourlourou]

Voici la différence de rendu, qui ne laisse de me plonger dans la perplexité...

[Paul TOTH]

attend "PRT = TRGBTripleArray absolute PBA" tu fais un absolute d'un record vers un pointeur ?

PS: pourquoi utiliser un MemoryStream pour enregistrer sur disque ?!

[tourlourou]

Merci pour tes remarques.

TMemoryStream : je suis d'accord ! Je n'utilise presque que ça, mais partiellement en raison d'un dérivé que j'ai codé et permettant de le faire pointer sur une portion seulement de la mémoire d'un autre => découpage facile, en lecture seule, sans recopie de données, pour en fournir une section à une méthode (LoadFromStream d'une image dans un flux, par exemple).

Pour l'absolute, il y a effectivement une différence de type, même si le compilo doit déréférencer comme si c'était la même chose. Et puis, même si ce n'est pas beau (mea culpa) on retrouve l'image, à défaut de ses couleurs. Ça ne doit donc pas interférer (à tester, cela dit).

[Gouyon]

Je remarque que tu n'as pas péciser le format des pixels. Le problème pourrait venir de là

[Paul TOTH]

Merci pour tes remarques.

TMemoryStream : je suis d'accord ! Je n'utilise presque que ça, mais partiellement en raison d'un dérivé que j'ai codé et permettant de le faire pointer sur une portion seulement de la mémoire d'un autre => découpage facile, en lecture seule, sans recopie de données, pour en fournir une section à une méthode (LoadFromStream d'une image dans un flux, par exemple).

Pour l'absolute, il y a effectivement une différence de type, même si le compilo doit déréférencer comme si c'était la même chose. Et puis, même si ce n'est pas beau (mea culpa) on retrouve l'image, à défaut de ses couleurs. Ça ne doit donc pas interférer (à tester, cela dit).

non mais absolute c'est très bien, faut juste savoir s'en servir

tu as un record d'un côté et un pointeur de l'autre !

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
 
type
  // pixel RGB ou YUV
  TYUV3=packed record
  case Boolean of
    True : (Blue, Green, Red: Byte); // = TRGBTriple
    False: (Y, U, V: Byte);
  end;
 
  // ligne de pixels
  TPRT=array of TYUV3;    
 
var
  PBA: PByteArray;
  PRT: ^TPRT absolute PBA; // pour traiter le buffer par octet, RGBTriple, ou YUV

il manque un "^" devant TPRT...PByteArray c'est un type à toi ou un pointeur vers un tableau dynamique - et donc un pointeur vers un pointeur ?

[tourlourou]

@Gouyon : je pense que le code suivant suffit à définir le format des pixels

ScanlineImage:=TLazIntfImage.Create(0, 0, [riqfRGB]);

Mais un peu plus de documentation ne m'aurait pas fait de mal... (je n'ai pê pas su la trouver)

@Paul : une variable de type PByteArray est un pointeur sur un tableau fixe de 32k éléments et une variable de type TPRT pointe sur un tableau ouvert : c'est moche, mais finalement ça permet de retomber sur ses pattes au fonctionnement ! Il me faudra corriger les déclarations pour être plus rigoureux, car ça m'avait échappé (d'autant plus facilement que ça fonctionne).

[Paul TOTH]

@Gouyon : je pense que le code suivant suffit à définir le format des pixels
Mais un peu plus de documentation ne m'aurait pas fait de mal... (je n'ai pê pas su la trouver)

@Paul : une variable de type PByteArray est un pointeur sur un tableau fixe de 32k éléments et une variable de type TPRT pointe sur un tableau ouvert : c'est moche, mais finalement ça permet de retomber sur ses pattes au fonctionnement ! Il me faudra corriger les déclarations pour être plus rigoureux, car ça m'avait échappé (d'autant plus facilement que ça fonctionne).

ah oui, j'ai lu trop vite, c'est un tableau ouvert...donc un pointeur. En fait ça ne me serait jamais pas venu à l'idée de le faire comme ça

en fait c'est super bizarre cette classe TLazIntfImage

[ChPr]

Voici la différence de rendu, qui ne laisse de me plonger dans la perplexité...

L'analyse des deux images montre qu'il y a un problème flagrant de nombre d'octets par pixel (3 ou 4).

L'image de gauche est celle de droite compressé sur un espace des 3/4 de celle de droite. La quart restant est rempli de je ne sais quoi.

Maintenant, quel le problème ???

Cordialement.

Pierre

[tourlourou]

Je cerne mieux le problème, sans le comprendre complètement...

Sous Ubuntu / Lazarus 64, le LazIntImage est bien créé avec un format pf24Bit mais stocké en interne sous forme BGRA sans canal alpha.


RGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBARGBA : ce qu'il attend
RGBRGBRGBRGBRGBRGBRGBRGBRGBRG : ce que je lui colle
RGB GBR BRG RGB GBR BRG RGB ................ : ce qu'il transmet (?) au Bitmap
Tiens donc, ça fait du gris ?

Bref, problème en passe d'être résolu, sauf que j'obtiens parfois une "opération de pointeur incorrecte" lors d'un ScanLine (qui n'est pas le dernier), avec certains clichés : il reste à déverminer !