Portabilité code BitMap

Version imprimable

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:

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.

10/06/2012, 21h53
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:

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 :mrgreen:
10/06/2012, 21h55
Paul TOTH

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

Je ne crois pas :

Code:

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

11/06/2012, 09h31
tourlourou

1 pièce(s) jointe(s)

Voici la différence de rendu, qui ne laisse de me plonger dans la perplexité...
11/06/2012, 11h21
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 ?!
11/06/2012, 12h35
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).
11/06/2012, 12h40
Gouyon

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

Citation:

Envoyé par 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).

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:

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 ?

11/06/2012, 16h49
tourlourou

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

Citation:

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).
11/06/2012, 18h35
Paul TOTH

Citation:

Envoyé par tourlourou

@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 :)
11/06/2012, 19h40
ChPr

Citation:

Envoyé par tourlourou

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
12/06/2012, 18h47
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 !