IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Lazarus Pascal Discussion :

[Linux] TImage.Picture.Bitmap vide en mode pf32bit [Lazarus]


Sujet :

Lazarus Pascal

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Expert confirmé
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    11 127
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 11 127
    Par défaut [Linux] TImage.Picture.Bitmap vide en mode pf32bit
    Bonjour,

    Oui, c'est encore moi avec mes misères de TImage, TBitmap, PixelFormat et tout ce foutoir immonde...

    Tout est dans le titre, et les détails suivent, mais tout d'abord je tiens à préciser que j'ai longtemps, très longtemps résisté (comprendre : retourné le web dans tous les sens sans rien trouver de concluant) avant de venir pleurer ici, mais là, au bout de 3 jours de vaines recherches, je n'en peux plus ...

    Alors, pour résumer, sous Linux, si j'utilise aBitmap.PixelFormat := pf32bit; le TImage propriétaire de ce aBimap est vide alors qu'en enregistrant avec aBitmap.SaveToFile('test32.bmp'); ce aBitmap, le fichier, lui, est tout bon :
    Nom : test_Fossie.png
Affichages : 394
Taille : 431 octets en beige la fiche, en noir l'image 80x80, en jaune et bleu un dessin.

    Voilà le bout de code, normalement avec une TImage (image4) et un bouton sur une fiche ça devrait le faire :
    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
    procedure TForm1.btnTestFromFossieClick(Sender: TObject);
    // examples/canvas_test
      function BytesPerPixel(APixelFormat: TPixelFormat): integer;
      begin
        Result := -1;
        case APixelFormat of pf8bit:result:=1;pf16bit:result:=2;pf24bit:result:=3;pf32bit:result:=4;end;
      end;
      procedure WorkWithCanvas(aBitmap: TBitmap);
      begin
        aBitmap.PixelFormat := pf24bit; // 24 ok, 32 vide
        aBitmap.Width  := 80;
        aBitmap.Height := 80;
        Image4.Width:=80; Image4.Height:=80; // ici ou en fin de proc = pareil, sert à rien...
        aBitmap.Canvas.Brush.Color := clBlue;
        aBitmap.Canvas.Pen.Color := clYellow;
        aBitmap.Canvas.Pen.Width := 5;
        aBitmap.Canvas.Rectangle(20, 20, 60, 60);
    //    Caption:=IntToStr(BytesPerPixel(Image4.Picture.Bitmap.PixelFormat));//ok 4 si 32
    //    aBitmap.SaveToFile('test32.bmp'); // OK OK OK !
      end;
    begin
      Image4.Picture.Bitmap.PixelFormat := pf32bit; // forcé mais sert à rien
      Caption:=IntToStr(BytesPerPixel(Image4.Picture.Bitmap.PixelFormat));//3 par défaut
      WorkWithCanvas(Image4.Picture.Bitmap);
    end;
    C'est inspiré des exemples fournis avec la distrib, où j'avais déjà noté en son temps, que ça ne fonctionnait pas en pf32bit sous Linux (à croire que les exemples ne sont qu'à moitié testés ).

    Un dernier mot à propos de cette construction où le bouton appelle une proc qui va bidouiller le Bitmap de l'image : c'est parce que dans un autre projet c'est la même construction sauf que le Bitmap y est bidouillé à grands coups de pointeurs et autre Scanline, et ça y fonctionne !, mais la chose n'est pas reproductible avec cet exemple simple (sinon je ne serais pas là).
    Vous allez me dire, mais pourquoi faire simple quand on peut faire compliqué, c'est ça ? Je n'ai pas la réponse, mais j'ai une question simple : quelle instruction manque-t-il à ce code pour que je puisse enfin voir mon joli dessin dans cette TImage en mode 32 bits ?

    Mon autre problème, aussi, c'est que j'en ai franchement marre de passer des jours et des jours sur les forums, à lire des solutions dont on dirait, d'après la discussion, que ça va fonctionner mais non, pas chez moi...
    Et il y a aussi les discussions où ça part bien, avec des solutions auxquelles l'OP répond que chez lui ça ne va pas, et plus de réponse de la part des helpers : un brave mystère, ça, que de laisser ainsi les gens le bec dans l'eau...
    Le nombre de discussions que j'ai pu voir comme ça, non finies, sur forum.lazarus.freepascal.org, c'est impressionnant !
    Et totalement décourageant...

  2. #2
    Rédacteur

    Avatar de gvasseur58
    Homme Profil pro
    Cultivateur de code (bio)
    Inscrit en
    Février 2013
    Messages
    1 436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Cultivateur de code (bio)
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2013
    Messages : 1 436
    Billets dans le blog
    84
    Par défaut
    Salut Jipété !

    Je m'absente quelques jours et voilà que je te retrouve empêtré dans les dessins et peintures en tous genres .

    Je suis toujours un peu surpris quand je te vois tripoter la propriété PixelFormat qui n'a pas de rôle fondamental en dehors de Scanline qui n'est justement pas portable .

    PixelFormat ne fait pas grand chose, car cette propriété est en attente d'être complétée

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    procedure TCustomBitmap.SetPixelFormat(AValue: TPixelFormat);
    begin
      if AValue = FPixelFormat then Exit;
      {$IFDEF VerboseLCLTodos}{$note todo copy image into new format }{$ENDIF}
      FreeImage;
      FPixelFormat := AValue;
    end;
    Moralité : si le format est bon, on sort sans rien faire ; si le format change, on libère l'image sans faire de copie

    En fait, les outils que tu utilises sont vraiment basiques. Il est plus que conseillé de passer à des bibliothèques comme BGRABitmap ou de travailler avec des classes graphiques non natives : elles sont fiables et vraiment indépendantes des plateformes (voir ici - en anglais pour l'essentiel). Seul problème : elles demandent plus de "manœuvres" pour être utilisées...

    @+ !
    Accès à mon site et à mon blog. Actualités, cours et ressources Delphi, Lazarus et Pascal.
    Pensez à la balise - Quelqu'un vous a aidé ou vous appréciez une intervention ? Pensez au

  3. #3
    Expert confirmé
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    11 127
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 11 127
    Par défaut
    Bonsoir Gilles,

    Content de titiller ta curiosité

    Alors tu vas rire :
    Citation Envoyé par gvasseur58 Voir le message
    Je suis toujours un peu surpris quand je te vois tripoter la propriété PixelFormat qui n'a pas de rôle fondamental en dehors de Scanline qui n'est justement pas portable .
    J'aime bien cette histoire de Scanline et sa rapidité foudroyante ! Et par ailleurs, en étudiant ça, ça m'apprend plein de trucs à côté, bientôt à parler russe, si ça continue
    Bon, pour l'instant, c'est plutôt gogol traduction qui me file un coup de main car, crois-le si tu veux mais, peu après avoir posté ici, je suis tombé sur un forum en .ru avec deux snippets ultra-courts qui m'ont inspiré au point de les mettre en œuvre, traduction comprise !
    Et bien m'en a pris ! ! !

    La première entrée était la question d'un gars comme moi, qui n'avait aucun résultat en pf32bit sous Linux (Bitmap.PixelFormat := pf32bit; // It does not work, but if replaced by pf24bit, then everything is fine), et la suivante était la solution (avec des commentaires du genre "c'est n'importe quoi l'implémentation pf32 sous Linux, d'autant plus que pf24 se comporte comme pf32" ! Ambiance...).
    Et j'ai rarement vu un code aussi succinct : en quelques lignes c'est torché ! (j'ai rajouté qq commentaires) :
    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
    42
    43
    44
    45
    procedure TForm1.btnRusseClick(Sender: TObject);
    TYPE // http://freepascal.ru/forum/viewtopic.php?t=11041&p=95820
         // c'est tout frais, ça date du 20 avril
        TRGBQuadArray = ARRAY[WORD] OF INTEGER;
        pRGBQuadArray = ^TRGBQuadArray;
        //réponse
        T = array[0..100000] of Byte;
        P = ^T;
      VAR
        i,j   :  INTEGER;
        Bitmap:  TBitmap;
        row   :  pRGBQuadArray;
        //réponse
        q,w: integer;
        A: P;
    begin
      Bitmap := TBitmap.Create;
      TRY
        Bitmap.PixelFormat := pf32bit; // не работает, но если заменить на pf24bit, то всё отлично
                                       // It does not work, but if replaced by pf24bit, then everything is fine
        // et ça fonctionne très bien avec la correction apportée par la réponse !
        Bitmap.Width  := 320;
        Bitmap.Height := 240;
        { // original :
        FOR j := 0 TO Bitmap.Height-1 DO
        BEGIN
          row := Bitmap.Scanline[j];
          FOR i := 0 TO Bitmap.Width-1 DO
            row^[i] := i*j; // chapeau !
        END; }
        // réponse :
        for q := 0 to Bitmap.Height-1 do begin
          A := Bitmap.Scanline[q];
          for w := 0 to Bitmap.Width-1 do begin
            A^[w*4]   := 255;   //blue    // chapeau aux 4 lignes !
            A^[w*4+1] := 0; //green   
            A^[w*4+2] := 0;   //red    
            A^[w*4+3] := 127; //alpha  
          end;
        end;
        Image4.Picture.Graphic := Bitmap;
      FINALLY
        Bitmap.Free;
      END
     end;
    Vous voulez lire les commentaires ?

    bitmap.pixelformat = pf24bit;
    This scene is painted correctly in green.
    Which means that 4 bytes or has no effect , i.e. apparently it is present even in Linux 24bit mode.

    if you change the [w*4 par [w*3, and comment out the line A[w*4+3]:= 255 //alpha, it will zakryshivanie bands. ???????????
    and paint is only 3/4 of the whole scenebitmap. That once again confirms that it is 24bit mode 4-byte mode.

    bitmap.pixelformat = pf32bit;
    This situation is strange mode.

    use the code as written above, with the filling of all 4 bytes ( the color should be green) very fine strips. gray background of some sort.
    in this case, if you change the code to fill only 3 bytes for the 3 groups of shading in green going fine,

    I tried to add one more 5th byte at one point, it does nothing, there is a crash.

    I come to the conclusion that pf24bit in Linux is pf32bit, and pf32bit - I do not know how it works - a wrong format. most likely it is pf24bit.
    pf32bit - normally draws only 3 bytes on the point, otherwise the picture is spoiled.


    Bon, il faut que je continue à travailler là-dessus (oui, j'ai écrit en haut que ça fonctionnait très bien mais c'est pas vrai : il y a toujours cette embrouille du mic-mac entre rouge demandé et bleu affiché, par exemple, mais au moins c'est affiché !) mais, mine de rien, j'ai considérablement progressé cet aprème, après trois jours de galère (bah, ma collection d'AV et autres SIGSEGV a bien augmenté, )

    Gilles, où (et comment) as-tu trouvé le bout de code que tu as posté ? Je n'ai rien trouvé dans 1.4.0

  4. #4
    Membre Expert

    Homme Profil pro
    au repos
    Inscrit en
    Février 2014
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : au repos

    Informations forums :
    Inscription : Février 2014
    Messages : 429
    Par défaut
    Salut JP,

    Le bout de code de Gilles se trouve dans "custombitmap.inc" (répertoire Windows : lcl\include).
    J'ai fait quelques tests sous Linux, et de fait, je n'arrive même pas à créer un simple TBitmap 32bits, dessiner un carré, et l'afficher sur un Canvas quelconque !
    Peut-être faut-il passer par une réinitialisation du RawImage (?)

    Si je trouve un truc, je te tiens évidemment au courant.

    Cordialement
    Thierry

  5. #5
    Expert confirmé
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    11 127
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 11 127
    Par défaut
    Salut Thierry, salut Gilles, salut les autres

    Citation Envoyé par ThWilliam Voir le message
    Le bout de code de Gilles se trouve dans "custombitmap.inc" (répertoire Windows : lcl\include).
    OK, merci pour le retour, je ne comprends pas pourquoi je n'arrive pas à remonter avec Ctrl-clic, je ne "sors" pas de Graphics...

    À l'occasion je regarderai ce qui se cache sous FreeImage, en attendant, ce que je peux dire, c'est que selon que je mets pf24bit ou pf32bit à l'endroit qui va bien, je gagne une image rouge ou une image bleue, toutes autres choses égales par ailleurs .


    Citation Envoyé par ThWilliam Voir le message
    J'ai fait quelques tests sous Linux, et de fait, je n'arrive même pas à créer un simple TBitmap 32bits, dessiner un carré, et l'afficher sur un Canvas quelconque !
    Peut-être faut-il passer par une réinitialisation du RawImage (?)
    Avec mon code ? Tiens, v'là avec quoi je bosse depuis ce matin, c'est que du bonheur (tout est là, un bouton et un TImage genre 400x300) :
    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
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    FUNCTION RGBtoRGBTriple(CONST red, green, blue:  BYTE): TRGBTriple;
    BEGIN
      WITH RESULT DO
      BEGIN
        rgbtRed   := red;
        rgbtGreen := green;
        rgbtBlue  := blue
      END
    END {RGBTriple};
     
    FUNCTION RGBAtoQuadBGRA(CONST red, green, blue, reserved: BYTE): TRGBQuad;
    BEGIN
      WITH RESULT DO
      BEGIN
        rgbRed   := red;
        rgbGreen := green;
        rgbBlue  := blue;
        rgbReserved := reserved;
      END
    END {RGBQuad};
     
    function BytesPerPixel(APixelFormat: TPixelFormat): integer;
    begin
      Result := -1;
      case APixelFormat of
        pf8bit : result := 1;
        pf16bit: result := 2;
        pf24bit: result := 3;
        pf32bit: result := 4;
      end;
    end;
     
    procedure TForm1.btnRussagainClick(Sender: TObject);
    const
      WSIZE = 320; // largeur
      HSIZE = 240; // hauteur
    TYPE // http://freepascal.ru/forum/viewtopic.php?t=11041&p=95820
      TArrayOfByte = array of TRGBQuad;
    //  TArrayOfByte = array of TRGBTriple; // raies verticales !?
    VAR
      bmp:  TBitmap;
      h, w: integer;
      AoB: TArrayOfByte;
      fs : TFileStream;
      FileSize: Integer;
      BPP: integer;
    begin
      bmp := TBitmap.Create;
      TRY
        with bmp do begin
          PixelFormat := pf32bit; // ou pf24bit, pour passer du rouge au bleu
          SetSize(WSIZE, HSIZE);
          BPP := BytesPerPixel(PixelFormat);
          FileSize := WSIZE * HSIZE * BPP;
          SetLength(AoB, FileSize);
          //Image4.Picture.Bitmap.PixelFormat:=PixelFormat; // mis pour voir si pf24/32 avait une influence, mais non
        end;
     
        //1-remplissage de l'array (ici demande = rouge transparent)
        for h := 0 to HSIZE-1 do
          for w := 0 to WSIZE-1 do
            //AoB[(h*WSIZE)+w] := RGBtoRGBTriple(255, 0, 0); // raies verticales !?
            AoB[(h*WSIZE)+w] := RGBAtoQuadBGRA(255, 0, 0, 127);
            //attention à l'ordre (selon 24 ou 32) ! /!\ B G R A  en mode 32 /!\ dans fic : 00 00 FF 7F
     
    //fs := TFileStream.Create('test3005_32.bin', fmCreate);
    //fs.WriteBuffer(pointer(AoB)^, FileSize);
    //fs.Free;
     
        //2-affichage (= génération du bmp)
        bmp.BeginUpdate;
          for h := 0 to HSIZE-1 do
            //Move(AoB[h], bmp.ScanLine[h]^, WSIZE*BPP); // /!\ Ne pas utiliser BPP ! (sinon carré rouge et quart noir en mode pf24)
            Move(AoB[h], bmp.ScanLine[h]^, WSIZE*4); 
        bmp.EndUpdate;
     
    //    bmp.SaveToFile('test3005_32_BGRA.bmp');
     
        Image4.Picture.Graphic := bmp;
      FINALLY
        bmp.Free;
      END
    end;
    Alors bon, Gilles, désolé mais je trouve que ça a son importance, et comme le disait le russe, pour avoir un joli rouge en mode pf24bit, il faut utiliser du TRGBQuad (= mode pf32bit) sinon tout ce qu'on gagne c'est des raies verticales toutes moches...

    Je suis en train de regarder avec l'éditeur hexa, mais effectivement, en mode pf32bit il y a un mic-mac de rouge demandé et transformé en bleu à l'affichage.
    Or, quand je regarde les datas brutes de chez brut en binaire pur, leur enregistrement est identique ! On voit des paquets (TRGBQuad) de 00 00 FF 7F qui se suivent, et heureusement, sinon je mangeais mon chapeau !

    J'en conclus que la gestion de ces datas par le Bitmap et ses routines interfère avec elles (confirmé par l'examen hexa des datas bmp (bmp.SaveToFile('fichier.bmp');) et impacte le résultat, les paquets d'octets dans les fichiers n'étant plus les mêmes.
    EDIT : j'ai regardé mes dumps avec le format BMP à côté, il en ressort que les pf24bit sont enregistrés BGR (comme j'ai pu le lire sur un autre site, d'ailleurs : "[...] l'ordre de l'alternance bleu, vert et rouge" alors que les pf32bit sont enregistrés RGBA...
    Nom : compar2432.png
Affichages : 476
Taille : 2,2 Ko
    À gauche ce dont je parle dans les commentaires du code, au centre le même un peu mieux, et à droite le mode pf32bit (désolé, l'explorateur de fichiers ne gère pas la transparence, qui est vraiment affichée par le TImage).
    /EDIT

    Nota : quand je parle de Bitmap, je parle du temporaire créé pour la manip et non pas celui inclus dans le TImage : ce TImage se contente d'afficher bêtement les données qui lui sont transmises.

    OK, pour le moment, je n'ai pas encore joué avec les Headers du format bmp, il y a peut-être des choses à définir là-dedans pour avoir un comportement plus rigoureux, mais une chose à la fois

    Citation Envoyé par ThWilliam Voir le message
    Si je trouve un truc, je te tiens évidemment au courant.
    Yes yes !

  6. #6
    Membre Expert

    Homme Profil pro
    au repos
    Inscrit en
    Février 2014
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : au repos

    Informations forums :
    Inscription : Février 2014
    Messages : 429
    Par défaut
    Re-bonjour JP.

    Bizarre, bizarre, ton histoire de fichiers bmp !

    Je viens de faire un test sous Linux Mint avec un simple TBitmap et en jouant avec quelques Canvas.Pixels.
    Enregistrement du bitmap et dans l'éditeur hexa :

    mode pf24bit : 3 octets par pixel , codage BGR
    mode pf32bit : 4 octets par pixel, codage BGRA (alors que chez toi : RGBA !!!)

    La modification de PixelFormat est donc effective ! Cela se vérifie dans les fichiers, que j'ai d'ailleurs lus sans problèmes dans Photoshop. Mais l'affichage écran : rien, rien, rien !!!

    Cordialement
    Thierry

  7. #7
    Expert confirmé
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    11 127
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 11 127
    Par défaut
    Ouaip, c'est encore moi : je touche au but.

    J'ai un peu regardé le mode pf24bit sous Lazarus dans Linux, pas dans le code, non, juste à l'écran, à observer ce qui s'affichait en jouant (à peine) sur les paramètres.

    D'abord, le bout de code publié en fin de matinée, je l'ai modifié pour travailler en pur 24 bits et avec un petit fichier (plus commode pour l'éditeur hexa), savoir (juste les modifs) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    const
      WSIZE = 32; // largeur
      HSIZE = 24; // hauteur
     
    //  TArrayOfByte = array of TRGBQuad;
      TArrayOfByte = array of TRGBTriple; // raies verticales
     
    //        AoB[(h*WSIZE)+w] := RGBAtoQuadBGRA(255, 0, 0, 127);
            AoB[(h*WSIZE)+w] := RGBtoRGBTriple(255, 0, 0);
     
    //        Move(AoB[h], bmp.ScanLine[h]^, WSIZE*4);
            Move(AoB[h], bmp.ScanLine[h]^, WSIZE*3);
    et ce qui s'affichait, c'était trop parfait (même si faux) pour être un problème aléatoire et pifométrique. Regardez (cette image a été beaucoup zoomée dans Gimp pour bien voir) :
    Nom : barrescolorées.jpg
Affichages : 259
Taille : 19,0 Ko

    Et comme j'en avais marre de m'user les yeux dans l'éditeur hexa où je voyais bien, en utilisant la première option d'enregistrement (le fs.WriteBuffer), qu'il y avait les bonnes données brutes dans le fichier .bin (que des blocs de 00 00 FF du début à la fin [Wikipédia : Si l'image est codée en 24 bits, chaque pixel est codé par un entier 24 bits (RVB), ordre little-endian, c'est-à-dire que les trois octets codent successivement les niveaux de bleu, vert et rouge.]), j'ai pris le fichier .bmp de l'image ci-dessus (deuxième option, le bmp.SaveToFile), j'ai viré les datas et n'ai gardé que l'en-tête pour remplacer ses données pourries par mon fichier .bin (sous Linux, cat fic.bin >> fic_nettoyé.bmp) et là, victoire !, j'avais un très beau fichier tout rouge !

    Conclusion : les mécanismes liés au TBitmap en 24 bits sous Linux sont tout pourris... Je comprends mieux pourquoi j'ai tant miséré ces derniers temps
    Je vous dis pas la taille de la bosse sur le front,

  8. #8
    Expert confirmé
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    11 127
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 11 127
    Par défaut
    Bonjour,

    Je ne résiste pas au plaisir de vous présenter le projet d'études final, rendu un peu joli par la barre de sélection du niveau de transparence, et tout ça fonctionne du feu de Dieu !

    Nom : scanlinefinal.jpg
Affichages : 357
Taille : 13,8 Ko

    Je me suis même amusé à faire générer une image de 1900 x 1100 (c'est presque les limites de mon écran 24") en 3 millisecondes, je ne sais pas si c'est bien-bien ou tout pourri mais en tout cas je suis content.

    Pour les puristes, je précise que le dégradé, pour avoir un vrai noir à 0,0,0 en haut à gauche et un vrai blanc à 255,255,255 en bas à droite, s'appuie sur un carré de 256 x 256, et donc, les traits rouge et jaune vous demandez-vous ? Ben le TImage pour l'affichage est dimensionné à 258 de haut et voilà.

    Ce que je peux dire, au bout du compte, c'est que ce genre d'image, construite ex nihilo en sachant exactement ce qu'on veut, permet de voir instantanément les moindres défauts d'algorithme, et c'est bien pratique pour corriger des bugs cachés, genre l'affichage était bon en carré mais foirait en rectangle, ou la réapparition des raies verticales (si si ! ) si la largeur de l'image était supérieure à 256 --> mise en œuvre de ratio et de règle de 3 et hop !

    Merci de m'avoir lu et supporté, merci pour les conseils (même si certains ne seront pas suivis tout de suite -- Thierry ), à bientôt pour de nouvelles aventures...
    Have fun !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 8
    Dernier message: 12/10/2011, 21h54
  2. [WD12E] Table vide en mode AffichageSeulement
    Par no_me_entero dans le forum WinDev
    Réponses: 3
    Dernier message: 29/05/2009, 08h28
  3. TImage : est-il vide ?
    Par qi130 dans le forum Composants VCL
    Réponses: 2
    Dernier message: 29/12/2007, 11h18
  4. VS 2005 Fenêtre propriétés vide en mode source
    Par yann47 dans le forum VB.NET
    Réponses: 2
    Dernier message: 18/12/2007, 11h29
  5. TImage et BitMap
    Par jcs2 dans le forum Composants VCL
    Réponses: 2
    Dernier message: 15/10/2005, 16h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo