TBitMap et Scanline

Version imprimable

Voir 40 message(s) de cette discussion en une page

29/12/2013, 17h31
Jipété

Citation:

Envoyé par Roland Chastain

Bravo Jipété ! :ccool:

Sans vouloir te commander, si tu voulais bien poster le projet complet, je serais preneur. :)

Merci merci, mais merci aussi à vous tous ;)

Laisse-moi quelques heures, histoire de faire le ménage dans tous les commentaires et autres ShowMessage dont mon brouillon est truffé :mrgreen:

Citation:

Envoyé par Roland Chastain

Est-ce que ça ne mériterait pas même d'être ajouté dans nos sources (éventuellement en incluant la version BGRABitmap) ?

Euh, honnêtement je ne sais pas, ce n'est qu'une petite bricole pour afficher des cercles :mouarf:

Bon, c'est vrai aussi que quelque part on a implémenté ce ScanLine manquant au TBitmap, on est trop forts (surtout Paul :D) !

On en reparle (j'attends les commentaires d'Yves et Paul, et je suis très perturbé par cette inversion rouge/bleu 8O)...
29/12/2013, 18h16
Jipété

Citation:

Envoyé par Jipété

(...) je suis très perturbé par cette inversion rouge/bleu 8O)...

Citation:

Envoyé par Jipété

Fonctionne en RESULT.PixelFormat := pf24bit; et RESULT.PixelFormat := pf32bit;

[ EDIT ] avec un curieux effet de bord : l'image ci-dessus vient suite à pf24bit. Si je mets pf32bit, le rouge et le bleu sont inversés :aie: [ /EDIT ]

Bon, ben il semblerait qu'en virant cette ligne RESULT.PixelFormat := pfXXbit;, ça ne fasse ni chaud ni froid au reste du code :mrgreen:, et à l'objet Bitmap qui semble être créé par défaut avec pf24bit.

Donc ligne virée --> problème disparu !
29/12/2013, 18h36
Paul TOTH

Citation:

Envoyé par Jipété

Bon, ben il semblerait qu'en virant cette ligne RESULT.PixelFormat := pfXXbit;, ça ne fasse ni chaud ni froid au reste du code :mrgreen:, et à l'objet Bitmap qui semble être créé par défaut avec pf24bit.

Donc ligne virée --> problème disparu !

ce qui voudrait dire qu'il est toujours en 32bits, puisque tu utilises un pRGBQuadArray qui est en 32 bits évidemment (non c'est pas évident ?)

alors petit rappel sur les bitmaps

8bit: un pixel = 1 octet = indice de la couleur dans la palette de 256 couleurs
16bits : un word = couleur RGB (Rouge Vert Bleu) sur 5,6 et 5 bits, 65536 couleurs maxi
24bits: 3 octets (RGBTriple) = couleur RGB 8bits chaque
32bits: 4 octets (RGBQuad) = couleur RGBA 8 bits chaque, A est le canal alpha utilisé habituellement pour la transparence.

ta variable "row" doit donc être d'un type compatible avec le format du Bitmap...voir dans la doc Lazarus pourquoi tu as toujours du 32 bits, car ce n'est pas le cas sous Delphi ou le format de ScanLine est directement influencé par le PixelFormat du Bitmap

C'est pour les problèmes de PixelFormat que j'imposais le type dans le RawImage :

Code:

1
2
3
4
5
6
7
  with RawImage // intermédiaire d'initialisation
  do begin
    Init;
    // pour compatibilité, création forcée BitMap pf24Bit dans un format BGRA 32 bits
    Description.Init_BPP32_B8G8R8_BIO_TTB(FWidth, FHeight);
    CreateData(True);
  end;

Le RawImage servant à initialiser un TLazIntfImage :

Code:

1
2
3
4
5
6
  ScanlineImage:=TLazIntfImage.Create(0,0);
  with ScanlineImage
  do begin
    SetRawImage(RawImage);
    ScanlineSize:=DataDescription.BytesPerLine;
  end;

Le TLazIntfImage est indépendant de la plateforme et propose GetDataLineStart(aRow: integer) qui est l'équivalent du ScanLine.

Pour BGRA, je reprends juste une définition de type qui n'est pas dans mes uses :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
uses
  Classes, SysUtils, Graphics, Math, IntfGraphics, LclIntf, GraphType, LCLType, FPImage;
 
type
  // pixel au format RGB (le canal Alpha est ajouté pour compatibilité)
  TBGRAPixel=packed record
  {$IFDEF FPC_LITTLE_ENDIAN}
    Blue, Green, Red, Alpha: Byte; // Delphi, Intel, par exemple
  {$ELSE}
    Alpha, Red, Green, Blue: Byte; // PowerPC
  {$ENDIF}
  end;

2 pièce(s) jointe(s)

Citation:

Envoyé par Paul TOTH

ce qui voudrait dire qu'il est toujours en 32bits, puisque tu utilises un pRGBQuadArray qui est en 32 bits évidemment (non c'est pas évident ?)

Ben vi, c'est évident, sauf que mon ShowMessage est formel : pf24bit.

Pourquoi crois-tu que j'ai écrit que ça me perturbait ce truc ? :mrgreen:

Citation:

Envoyé par Paul TOTH

(...) voir dans la doc Lazarus pourquoi tu as toujours du 32 bits, car ce n'est pas le cas sous Delphi ou le format de ScanLine est directement influencé par le PixelFormat du Bitmap

Nooooon, pas la doc Lazarus, c'est une vraie misère et une plaie sans nom, ce truc :cry:

Ce que je trouve dans custombitmap.inc, c'est le constructeur :
Code:

1 2 3 4 5 constructor TCustomBitmap.Create; begin inherited Create; FPixelFormat := pfDevice; end;
Mais mon test avec ShowMessage incluait tous les pfXXX possibles et il m'a toujours sorti pf24bit.
Citation:
Envoyé par tourlourou
C'est pour ça que je forçais le type dans le RawImage :
Code:

1 2 3 4 5 6 7 with RawImage // intermédiaire d'initialisation do begin Init; // pour compatibilité, création forcée BitMap pf24Bit dans un format BGRA 32 bits Description.Init_BPP32_B8G8R8_BIO_TTB(FWidth, FHeight); CreateData(True); end;
J'ai essayé, Yves, j'ai essayé plein de variantes de cet Init_... mais ça n'a rien changé :koi:

À la demande générale de Roland, le code de l'unité, et une image finale (pour ceux qui voudront tester : un TImage de 480x480, 2 boutons {fonction 'Print' non implémentée [spécifique à Windows]}, un TComboBox, un TLabel et 3 TCheckBox).
Pièce jointe 133687

Pièce jointe 133688

Enjoy, mais méfiance, voici ce qu'on peut lire dans l'aide de TRawImage :

Citation:

This object currently is subject to refactoring, don't use it in application code.

:aie:

Bonjour à tous,

je reviens deux minutes sur cette chose perturbante :mrgreen:

J'ai créé vite fait un prog de test complètement en dehors du projet de base, les résultats sont en commentaires, tout est là :

Code:

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
function Createbmp(i: integer): TBitmap;
var
  bmp: TBitmap;
 
  procedure ShowPF;
  begin
    case bmp.PixelFormat of
      bmp.PixelFormat.pf1bit : ShowMessage('1');
      bmp.PixelFormat.pf4bit : ShowMessage('4');
      bmp.PixelFormat.pf8bit : ShowMessage('8');
      bmp.PixelFormat.pf15bit : ShowMessage('15');
      bmp.PixelFormat.pf16bit : ShowMessage('16');
      bmp.PixelFormat.pf24bit : ShowMessage('24');
      bmp.PixelFormat.pf32bit : ShowMessage('32');
      bmp.PixelFormat.pfCustom : ShowMessage('cust');
      bmp.PixelFormat.pfDevice : ShowMessage('dev');
    end;
    ShowMessage(IntToStr( bmp.RawImage.Description.Depth) +'---'+
                IntToStr( bmp.RawImage.Description.BitsPerPixel) +'---'+
                IntToStr( bmp.RawImage.Description.BytesPerLine)
                );
  end;
begin
  bmp := TBitmap.Create;
  bmp.SetSize(i, i); // 480
  ShowPF; // --> *24* & 24---32---1920
 
  bmp.PixelFormat := pf16bit;
  ShowPF; // --> *16* & 24---32---1920
 
  bmp.Free;
end;

C'est ce "1920" (= 480 x 4) et donc ce "4" qui m'a mis sur la piste du TRGBQuad.
Mais j'avoue que tout cela est bien mystérieux, surtout quand PixelFormat est à 16 et qu'on a quand même 32 BitsPerPixel...

Bonne journée, et bon réveillon !

31/12/2013, 11h30
Roland Chastain

Bonjour Jipété !

Je viens d'essayer ton programme. Je n'obtiens pas le résultat que tu as mis en commentaire. Voici ce que j'obtiens :

Citation:

24, 24---24---1440
16, 24---24---1440

Je n'ai pas l'explication.

Bon réveillon à toi !

dans TCustomBitmap.RawimageNeeded, tu as ce code qui à mon avis fait passer le format du RawImage en 32bits

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
// setup ImagePtr, fill description if not set
  if ImagePtr^.Description.Format = ricfNone
  then begin
    // use query to get a default description without alpha, since alpha drawing
    // is not yet supported (unless asked for)
    // use var and not pixelformat property since it requires a rawimagedescription (which we are creating)
    case FPixelFormat of
      pf1bit: Flags := [riqfMono, riqfMask];
      pf4bit,
      pf8bit: Flags := [riqfRGB, riqfMask, riqfPalette];
      pf32bit: Flags := [riqfRGB, riqfMask, riqfAlpha];
    else
      Flags := [riqfRGB, riqfMask];
    end;
    ImagePtr^.Description := QueryDescription(Flags, ImagePtr^.Description.Width, ImagePtr^.Description.Height);
    // atleast for now let pixelformat reflect the created description
    FPixelFormatNeedsUpdate := True;
  end;

et dans TWidgetSet.RawImage_QueryDescription

Code:

1
2
3
4
 
  else if riqfRGB in AFlags
  then begin
    ADesc.Format := ricfRGBA;

ce qui me fait dire que RawImage n'est pas comme sous Delphi un accès direct aux pixels de l'image, c'est un tableau de pixels construit dynamiquement à partir de l'image...mais c'est probablement lié au multiplateforme qui ne doit pas permettre l'accès aux pixels partout.

02/01/2014, 00h18
Jipété

Salut tout le monde,

tous mes vœux, plein de bonnes choses et de codes sans bugs :mouarf:

Citation:

Envoyé par Roland Chastain

Bonjour Jipété !

Je viens d'essayer ton programme. Je n'obtiens pas le résultat que tu as mis en commentaire. Voici ce que j'obtiens :

Citation:

24, 24---24---1440
16, 24---24---1440

Je n'ai pas l'explication.

Bon réveillon à toi !

1440 = 480 * 3. Tu devrais essayer de remettre row: pRGBTripleArray; juste pour voir si ça change quelque chose...

Et sinon, OS ? 32/64 ?
Si Linux, environnement de bureau, window manager, tout ce genre de choses...

Perso j'ai aussi testé dans une VM qui tourne sous Debian Wheezy 7.2 / 32 et Xfce, et ça roulait. Mais cette VM est hébergée sur la machine où j'ai dépatouillé tout ça, peut-être que ça aide.

Ou pas : mon environnement "host" est sous lxde et je n'ai pas de transparence, par exemple ; et pourtant la VM sous Xfce l'a, ainsi que mes VM's Windows, c'est un peu mystérieux pour moi que des VM's aient plus de pouvoir (si je puis dire) que la machine qui les héberge 8O
04/01/2014, 10h54
Roland Chastain

Citation:

Envoyé par Jipété

Tu devrais essayer de remettre row: pRGBTripleArray; juste pour voir si ça change quelque chose...

Voilà, j'ai testé l'unité que tu as postée. :ccool:

Je confirme que chez moi (Windows 8), c'est bien la version TRGBTriple qui donne le bon résultat.

A noter, j'ai dû remplacer rgbRed par rgbtRed, etc.
04/01/2014, 12h39
Jipété

Yep !

Citation:

Envoyé par Roland Chastain

Voilà, j'ai testé l'unité que tu as postée. :ccool:

Ouf ! Je croyais que tu nous avais zappés, :mrgreen:

Citation:

Envoyé par Roland Chastain

Je confirme que chez moi (Windows 8), c'est bien la version TRGBTriple qui donne le bon résultat.

Impec !
Plus qu'à faire une détection de plate-forme au lancement, et border la déclaration de row (et son utilisation, voir § suivant) par des {$IFDEF type_os} et hop !
Je laisse ça comme un exercice pour un lecteur intéressé (comme on dit, des fois, dans des sources) :mouarf:

Citation:

Envoyé par Roland Chastain

A noter, j'ai dû remplacer rgbRed par rgbtRed, etc.

Vi, me semble bien l'avoir vécu et avoir oublié de le signaler :oops:
Merci à toi.

Bon wik,

Voir 40 message(s) de cette discussion en une page