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

  1. #1
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut Travailler avec TBitmap et des fichiers bmp sous Linux

    Bonjour,

    avant que je ne jette définitivement l'éponge, je viens voir si quelqu'un aurait une idée.

    Le contexte : un vieux couple Lazarus/FreePascal (mais comme le graphisme n'a pas été mis à jour, ce n'est pas un problème) tournant dans une machine Debian 32 bits, et des fichiers bitmap à 32 bits par pixel.

    Comme on le voit sur l'image ci-dessous, les fichiers sont bien ouverts avec The Gimp (ligne du haut) et l'outil en Lazarus (en bas) doit lui aussi les ouvrir, les afficher (à gauche), les dupliquer et afficher la copie (à droite).
    Nom : rendus_gimp_laz.jpg
Affichages : 167
Taille : 44,6 Ko

    On voit tout de suite que si pour l'un ça se passe bien, pour l'autre ce n'est pas du tout ça.
    Le problème n° 1, c'est que je ne vois aucune différence dans les headers des fichiers ; bien sûr les tailles sont différentes, mais la chose qui aurait pu générer ce résultat catastrophique est la même pour les deux fichiers, je veux parler du "20" à l'adresse 1C, qui veut dire 32 bits.

    Je confirme cette valeur avec un peu de calcul sur les dimensions :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    //600x400x32 :    600x400 = 2400000
    //                et l'adresse 22 23 24 25 (biSizeImage) contient 00 A6 0E 00 soit 000EA600 soit 960000 soit 240000x4 donc pf32
    // 32bitkc :      250x250 = 62500
    //                et l'adresse 22 23 24 25 (biSizeImage) contient 90 D0 03 00 soit 0003D090 soit 250000 soit 62500 x4 donc pf32
    Alors, qu'est-ce que c'est qui met sa pagaille pour que je récupère cette collection de raies ? Voilà le début des headers, à partir de la ligne 30 c'est le début des datas, on s'en fiche.

    Nom : compar_hexa_xbr-32kc.jpg
Affichages : 157
Taille : 96,3 Ko

    Les plus observateurs remarqueront que le fichier du bas a des valeurs aux adresses 26-2D, ça concerne les informations de définition de l'image (improprement appelée "résolution", pas d'incidence normalement.

    Le problème n° 2 c'est qu'avec plein d'autres fichiers en 32 bits, ça se passe comme ça :

    Nom : 196x128x32.png
Affichages : 142
Taille : 3,4 Ko

    et pour avoir une image correcte à droite, il me faut basculer le code de copie en mode 24 bits (), genre
    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
    // pbD et pbS sont des pointeurs de bytes pour se balader 
    // en mode scanline dans la RawImage des TBitmap Source et Destination
    idx := 0;
    for w := 0 to (src.Width * 3)-1 do begin // byte par byte de g. à dte
      pbD^[idx] := pbS^[w];
      if ( (w+1) mod 3 = 0 ) then begin // w+1 pointe le 3e byte de la source
        // 1- inverser R et B dans la destination qu'on vient de traiter
        tempByte    := pbD^[idx-2];
        pbD^[idx-2] := pbD^[idx-0];
        pbD^[idx-0] := tempByte;
        // 2- ajouter le canal alpha puisqu'il le FAUT sous Linux SI la longueur est PAIRE
        // OU inférieure à 32, go figure !
        if src.Width < 32 then begin
          inc(idx);
          pbD^[idx] := 255;
        end else // longueur => 32, il faut tester si paire ou impaire
        if not Odd(src.Width) then begin 
          inc(idx);
          pbD^[idx] := 255;
        end;                      
      end;
      inc(idx);
    end;
    Une idée de comment solutionner ces pagailles et avoir un code maintenable (parce que là...) ?

    Merci,

    PS : j'ai testé avec TLazIntfImage, c'est un milliard de fois plus compliqué...
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  2. #2
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Bonjour,

    comme je sais que vous aimez les jolies images, en voilà une magnifique, assortie d'une interrogation énorme :
    (j'ai changé une couleur par rapport à celle d'hier, car noir sur noir c'était compliqué)

    Nom : copie_192x128x24+code.png
Affichages : 134
Taille : 25,8 Ko

    Tout le monde aura compris que le bout de code à droite est celui qui est utilisé pour générer la copie.
    pf24_S et _D sont des booléens déterminant le PixelFormat, le reste se devine sans souci.
    Bien.
    Le fichier est un bête 192x128 de 24 bits par pixel généré avec The Gimp.

    Et dans la copie, la zone noire fait 48 pixels de large ; d'où sort cette valeur ?
    Question subsidiaire : comment savoir s'il s'agit d'un pb de lecture de la source ou d'écriture de la destination ?

    Bon, ce 48 c'est quand même 192 / 4
    Ce "4" me mettant la puce à l'oreille, je fais un test rapide en remplaçant la ligne de balayage des bytes
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
      for w := 0 to (src.Width*3)-1 do begin // px à px de g. à dte sans padding
    par la même en plus long :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
      for w := 0 to (src.Width*4)-1 do begin // px à px de g. à dte sans padding
    ce qui, pour moi, n'a aucun sens quand on examine les valeurs dans le fichier source avec un éditeur hexa et qu'on voudrait faire une recopie à l'identique, mais en tout cas, il n'y a plus de zone noire à droite.

    Le plus fou, c'est que les fichiers générés en fin de copie sont strictement les mêmes : mêmes tailles sur le disque, mêmes contenus à l'éditeur hexa, sauf les bouts de ligne noirs, bien sûr.
    Quand je dis que ce sont les mêmes, je pense surtout en termes de taille et autre pixelformat, toutes choses censées impacter le type et le contenu des lignes.
    Les miniatures générées par Linux sur le Bureau :

    Nom : fic_good_et_bad.png
Affichages : 132
Taille : 33,9 Ko

    À y perdre son latin et y manger son chapeau...

    Bon week-end,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  3. #3
    Responsable Delphi

    Avatar de gvasseur58
    Homme Profil pro
    Cultivateur de code (bio)
    Inscrit en
    février 2013
    Messages
    1 394
    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 394
    Points : 19 634
    Points
    19 634
    Billets dans le blog
    84

    Par défaut

    Bonjour Jipété,

    Tu fournis des images, mais je crois que des fichiers à analyser par nous-mêmes seraient plus intéressants pour l'expérimentation ( et le CODE surtout !!!).

    Pour ce qui est du format bmp (que j'ai abandonné parce qu'il n'offre pas de canal alpha), il me semble que ton problème vient de tes images en 32 bits. Si tu regardes bien les spécifications de bmp, ce format est "factice" en ce sens qu'au maximum 24 bits sont gérés : un octet par couleur plus un indéterminé. Quand tu proposes une image bmp en 32 bits, tu devrais enlever pour chaque groupe de 3 octets l'octet de remplissage (voilà pourquoi quand tu passes par le format 24 bits, tout revient dans l'ordre).

    Ce qui est vrai, c'est que certains logiciels utilisent ce quatrième octet (en fait, le premier XRBG) pour gérer le canal alpha.

    Pour plus d'infos, voir le format bmp.

    Comme je fais ça loin de ma documentation (donc de mémoire), ces infos sont à vérifier !

    Excellent week-end,

    Gilles
    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

  4. #4
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Merci pour ta réponse, Gilles,

    2 choses :
    1- tu es trop windowsien, je t'assure que le bmp peut être utilisé avec 32 bits par pixel, d'ailleurs l'info est même dispo chez Microsoft (faut chercher biBitCount 32 dans les Members, 1re rubrique après Syntax)
    Chacun ensuite en fait ce qu'il veut, d'ailleurs l'option est bien présente dans The Gimp (j'avais donné en son temps une copie d'écran de la boîte de dialogue), mais ne nous dispersons pas.

    2- j'ai donc créé viteuf un microscopique projet de test sans aucune correction, qui se vautre lamentablement : projettest.zip
    Sous Linux.

    Nom : demotest.png
Affichages : 127
Taille : 61,3 Ko

    Parce que la maison ne reculant devant aucun sacrifice, j'ai démarré une machine virtuelle XP équipée d'un Laz 1.8.2 et, sans rien changer au code, les 2 fichiers présents dans l'archive s'affichent parfaitement.

    Comment veux-tu ne pas être découragé devant tant d'adversité ?
    EDIT :
    Je ne mets pas l'image des 6 carrés qui deviennent des rectangles pleins de rayures, vous la retrouverez dans mes posts.
    Bah :
    Nom : avec192x128x24.png
Affichages : 122
Taille : 7,8 Ko

    Un dernier mot à propos du projet : l'image jaune n'étant qu'une ligne de 7 pixels, c'est assez petit pour ne rien voir à l'écran, j'ai donc configuré Stretch := True pour les 2 TImage directement dans l'EDI, et le problème est présent dans les deux cas, donc là on le voit mieux.

    Enjoy,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  5. #5
    Responsable Delphi

    Avatar de gvasseur58
    Homme Profil pro
    Cultivateur de code (bio)
    Inscrit en
    février 2013
    Messages
    1 394
    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 394
    Points : 19 634
    Points
    19 634
    Billets dans le blog
    84

    Par défaut

    Salut Jipété,

    Merci pour les fichiers !

    1- tu es trop windowsien, je t'assure que le bmp peut être utilisé avec 32 bits par pixel, d'ailleurs l'info est même dispo chez Microsoft (faut chercher biBitCount 32 dans les Members, 1re rubrique après Syntax)
    Sans doute, mais il y a de quoi dans ce cas précis : bmp est quand même un format de Windows . Pour l'utilisation en 32 bits, je n'ai pas dit qu'elle n'existait pas, j'ai (sans doute maladroitement) dit qu'elle était factice avec son octet vide inutilisé.

    J'ai testé ton code sous Mint et le résultat est le même que celui que tu décris. Pour simplifier les problèmes, j'ai d'abord utilisé la méthode de copie toute simple avec Assign et j'obtiens bien la bonne copie (encore heureux !).
    Pour simplifier encore, je ne vais pas utiliser le composant TImage, car il n'est pas et ne peut pas être équivalent entre Windows et Linux pour des raisons internes aux OS (une question d'accès au canevas, je crois me souvenir, mais quelqu'un pourrait préciser sans doute - je vais essayer de retrouver la référence). Je vais plutôt m'appuyer sur un canevas d'une PaintBox, par exemple => je te tiens au courant.

    Gilles

    [EDIT] As-tu aussi pensé à tes travaux précédents avec l'ordre des octets ? Je te renvoie à une discussion que tu avais menée en... 2016 : https://www.developpez.net/forums/d1...ws-sous-linux/
    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

  6. #6
    Responsable Delphi

    Avatar de gvasseur58
    Homme Profil pro
    Cultivateur de code (bio)
    Inscrit en
    février 2013
    Messages
    1 394
    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 394
    Points : 19 634
    Points
    19 634
    Billets dans le blog
    84

    Par défaut

    Dis, tu ne crois pas que le problème rencontré est similaire à celui traité dans cette discussion ? Mêmes symptômes...

    https://www.developpez.net/forums/d1...l-enfer-terre/

    D'autre part, je pense que tu n'utilises pas TRawImage correctement, car tu supposes à tort que Windows et Linux gèrent de la même manière le bitmap. Regarde ici pour la description de TRawImageDescription.

    Personnellement, je préfère utiliser des bibliothèques comme BGRABitmap qui fonctionnent de manière moderne et efficace : plus rapides, plus polyvalentes (avec canal alpha et anticrénelage) et véritablement multiplateformes. Les outils standards de Lazarus le sont aussi tant qu'on essaye pas de sortir des techniques courantes.
    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

  7. #7
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Bonsoir Gilles (et les autres lecteurs),

    Citation Envoyé par gvasseur58 Voir le message
    Dis, tu ne crois pas que le problème rencontré est similaire à celui traité dans cette discussion ? Mêmes symptômes...
    Moui, c'est possible, pour tout te dire, j'avoue que je ne me souviens plus de quoi j'ai causé il y a deux ans (ou six mois !), pour la bonne et simple raison que lorsque j'ai un truc à faire, j'attrape le taureau par les cornes et je fonce.

    Et aussi que je n'ai pas encore trouvé de méthode définitive (entendre "fiable à 100 %") pour ouvrir les fichiers, tous les fichiers (enfin, les bmp, jpg et png d'abord, tif dans un second temps – pour les gif je m'appuierai sur l'excellent boulot de Jérôme). Résultat, j'aurais tendance à oublier ces vieilles discussions : à chaque nouveau problème une nouvelle solution, et les vieilles chausse-trappes réapparaissent,

    Citation Envoyé par gvasseur58 Voir le message
    Personnellement, je préfère utiliser des bibliothèques comme BGRABitmap qui fonctionnent de manière moderne et efficace : plus rapides, plus polyvalentes (avec canal alpha et anticrénelage) et véritablement multiplateformes. Les outils standards de Lazarus le sont aussi tant qu'on essaye pas de sortir des techniques courantes.
    Tu parles des compos BGRA, je l'entends bien, mais j'ai posté récemment une image (peut-être pas assez claire ?)
    Nom : lazpaint641_n_atool.png
Affichages : 121
Taille : 197,6 Ko
    où l'on voit bien que Lazpaint (qui s'appuie dessus) ne peut pas ouvrir un fichier que j'ouvre sans problème.
    Et il n'y a pas de message d'erreur, rien qu'un quadrillage genre calque transparent de Photoshop.

    Même souci avec un fichier .bmp d'origine os/2 que j'ouvre sans problème en m'appuyant sur les données du header, lire ci-après.
    Plus une embrouille avec un tif, qui me génère un AV quand j'ouvre le dossier le contenant.
    En haut l'explorateur Lazpaint, en bas celui de Linux :
    Nom : AV_fic-tif.png
Affichages : 115
Taille : 47,4 Ko

    Citation Envoyé par gvasseur58 Voir le message
    D'autre part, je pense que tu n'utilises pas TRawImage correctement, car tu supposes à tort que Windows et Linux gèrent de la même manière le bitmap. Regarde ici pour la description de TRawImageDescription.
    Le pourquoi du comment de mon rejet de TRawImageDescription : trop de déboires et de déconvenues, et je n'ai jamais compris pourquoi ce type remontait des informations différentes de ce qu'on peut voir en examinant le header d'un fichier avec un éditeur hexa (à tel point que je me suis bricolé une unité qui va lire ces infos plutôt que d'interroger ce TRID. Sans parler de la pauvreté de l'aide.

    Citation Envoyé par gvasseur58 Voir le message
    Pour simplifier encore, je ne vais pas utiliser le composant TImage, car il n'est pas et ne peut pas être équivalent entre Windows et Linux pour des raisons internes aux OS (une question d'accès au canevas, je crois me souvenir, mais quelqu'un pourrait préciser sans doute - je vais essayer de retrouver la référence). Je vais plutôt m'appuyer sur un canevas d'une PaintBox, par exemple => je te tiens au courant.
    avec plaisir, car c'est un composant que je n'utilise jamais : je ne me sens pas d'atomes crochus avec lui, il me semble confus, archaïque, et j'avoue que je trouve le TImage beaucoup plus simple et sympathique.

    Citation Envoyé par gvasseur58 Voir le message
    J'ai testé ton code sous Mint et le résultat est le même que celui que tu décris.
    Ceci est une bonne nouvelle, quelque part.

    Citation Envoyé par gvasseur58 Voir le message
    Pour simplifier les problèmes, j'ai d'abord utilisé la méthode de copie toute simple avec Assign et j'obtiens bien la bonne copie (encore heureux !).
    Pourquoi je ne l'utilise pas, et pourquoi je veux passer par les bytes ? Parce que j'ai trouvé deux projets en Delphi dont le sujet me passionne, je veux parler du traitement d'images et des manières de les redimensionner, et pour ça, il faut aller chercher les composantes de chaque pixel pour faire des calculs dessus.
    Donc tant que je ne peux pas faire des copies 1/1 pour commencer, je ne peux pas aller plus loin.

    Citation Envoyé par gvasseur58 Voir le message
    [EDIT] As-tu aussi pensé à tes travaux précédents avec l'ordre des octets ? Je te renvoie à une discussion que tu avais menée en... 2016 : https://www.developpez.net/forums/d1...ws-sous-linux/
    Non, je l'avais oubliée... J'y vais de ce pas.

    EDIT : je suis allé voir et je me rends compte aujourd'hui qu'il y a deux ans j'en savais beaucoup moins que maintenant...

    Il est bien, mon bout de code, elles sont jolies les images, mais on ne sait pas du tout si c'est la vérité qui est encodée dans les fichiers de sortie, pour la bonne et simple raison qu'il n'y en a pas !

    Si je reprends le projet de cet après-midi et que je fais enregistrer le bmp de sortie, il présente le même défaut que ce qu'on voit dans le TImage. Quelque part c'est bien, car il y a eu des cas dans mes autres tests de ces derniers jours où les deux étaient différents, en plus !

    Bon, pour en revenir à mon histoire de copie de bytes, j'ai fait un truc simple : rajouter un TMemo comme système de log,
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
          for w := 0 to (Width*3)-1 do begin
            pbD^[w] := pbS^[w];
            memo1.Lines.Add(inttostr(pbS^[w]) +'---'+inttostr(pbD^[w]));
          end;
          Caption := IntToStr(w); // 20, ok
          // padding -- attention : à commenter pour l'autre fichier
          for p := 1 to 3 do begin
            pbD^[w+p] := 0;
            memo1.Lines.Add(inttostr(pbD^[w+p]));
          end;
    et regarder le résultat (et c'est là qu'on s'arrache les cheveux, parce que les datas sont bonnes) :
    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
      0---  0
    255---255
    255---255
      0---  0
    255---255
    255---255
      0---  0
    255---255
    255---255
      0---  0
    255---255
    255---255
      0---  0
    255---255
    255---255
      0---  0
    255---255
    255---255
      0---  0
    255---255
    255---255
    0
    0
    0
    On voit bien que les 7 pixels sont strictement identiques, byte source à gauche, destination à droite), on a bien 0 255 255 7 fois, S comme D.
    Pourquoi ne le sont-ils pas dans le bmp, puisque ce qu'on voit c'est le contenu du bmp en mode "dissection sous le microscope" ?

    Sans doute parce que je crois être au plus bas niveau avec mon histoire de copie de bytes, mais ça ne doit pas être le cas et il doit y avoir des couches qui font leur (sale) cuisine entre les données du fichier et les instructions pour les traiter.
    C'est la seule explication que je vois.
    Parce que mine de rien,
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
            memo1.Lines.Add(inttostr(pbD^[w+p])); // ici les données sont bonnes
          end;
        end;
      bmp.EndUpdate();
      // et ici elles ne le sont plus, puisque si je n'enregistre pas, l'affichage est quand même en vrac
      bmp.SaveToFile(Application.Location + 'test1.bmp');
      image2.Picture.Bitmap.Assign(bmp);
    Voilà...
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  8. #8
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Bonjour,

    la nuit porte conseil, et ces rayures m'ont inspiré : trop parfaites pour être honnêtes, il n'y avait qu'une solution : la destination de la copie est en 32 bits.

    Et effectivement, après avoir rajouté un bouton sur la fiche, j'y ai copié.collé le code du Button1 puis lui ai apporté quelques modifs :

    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
    var
      wd,ws,h: integer;
      pbS,pbD: pByteArray;
      tmpbyte: Byte;
      dst: TBitmap;
    begin
      opd.InitialDir := Application.Location;
      if not opd.Execute then exit;
      load(opd.FileName);
      dst := TBitmap.Create;
      dst.PixelFormat := pf32bit;
      dst.Width  := Image1.Picture.Bitmap.Width;
      dst.Height := Image1.Picture.Bitmap.Height;
      dst.BeginUpdate();
      with Image1.Picture.Bitmap do
        for h := 0 to Height-1 do begin
          pbS := pByteArray(    RawImage.GetLineStart(h));
          pbD := pByteArray(dst.RawImage.GetLineStart(h));
          wd := 0;
          for ws := 0 to (Width*3)-1 do begin
            pbD^[wd] := pbS^[ws];
            if ((ws + 1) mod 3 = 0) then begin // = traitement du 3e byte de la source terminé
              // 1- R et B de la dest sont inversés
              tmpbyte := pbD^[wd-2];
              pbD^[wd-2] := pbD^[wd];
              pbD^[wd] := tmpbyte;
              // 2- il faut ajouter un 4e byte à la dest
              inc(wd);
              pbD^[wd] := 255;
            end;
            inc(wd); // pour avancer dans la dest
          end;
          Caption := IntToStr(ws)+'--'+IntToStr(wd); // 20--28
          // padding : plus besoin en pf32bit
        end;
      dst.EndUpdate();
      image2.Picture.Bitmap.Assign(dst);
      dst.Free;
    end;
    Et voilà.
    Reste plus qu'à tester avec ma collection de fichiers en 24 bits tordus ou étranges...

    Et ensuite il faudra trouver une procédure pour les sources en 32 bits.
    La voilà (je vous la laisse intégrer)
    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
      dst.BeginUpdate();
      with Image1.Picture.Bitmap do
        for h := 0 to Height-1 do begin
          pbS := pByteArray(    RawImage.GetLineStart(h));
          pbD := pByteArray(dst.RawImage.GetLineStart(h));
          for w := 0 to (Width*4)-1 do begin
            pbD^[w] := pbS^[w];
            if ((w + 1) mod 4 = 0) then begin // = traitement du 4e byte de la source terminé
              // R et B de la dest sont inversés
              tmpbyte := pbD^[w-3];
              pbD^[w-3] := pbD^[w-1];
              pbD^[w-1] := tmpbyte;
            end;
          end;
          // padding : plus besoin en pf32bit
        end;
      dst.EndUpdate();
    Elle fonctionne très bien avec le bmp 32 bits jaune généré par le button2, mais un sondage rapide montre que ça va être une vraie catastrophe avec plein d'autres fichiers de ma collection, à commencer par celui que j'ai montré hier sur lequel butte Lazpaint : moi aussi maintenant...

    Un exemple pour me pourrir le dimanche, et en plus la preview de l'opd (à g.) me colle la honte :

    Nom : previewok.png
Affichages : 103
Taille : 61,3 Ko

    Mes rendus sont rectangulaires, c'est normal, je rappelle que les TImage sont Stretched à True histoire d'agrandir le fichier jaune du départ qui n'occupe qu'une ligne de 7 pixels.

    La seule piste que je vois, pour l'instant, c'est que le 32 bits qui fonctionne bien a une version de header du fichier à 1, quand les autres sont à 4 (ou 5), avec des datas plus loin dans la structure du fichier.
    Mais si la preview s'en accommode, pourquoi le traitement du bmp ne s'en sort-il pas proprement ? C'est dément et illogique (ou buggé...)
    Va encore falloir que je parte dans des traitements de fou sur les tests de la version du header et ce genre de choses...
    Tiens, je vais me faire un café,


    Ah, si certains veulent jouer : 32bitsOK.bmp.zip
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  9. #9
    Responsable Delphi

    Avatar de gvasseur58
    Homme Profil pro
    Cultivateur de code (bio)
    Inscrit en
    février 2013
    Messages
    1 394
    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 394
    Points : 19 634
    Points
    19 634
    Billets dans le blog
    84

    Par défaut

    [EDIT Je n'avais pas rafraîchi mon écran et j'arrive aux mêmes conclusions que toi ! Je laisse le message, car il contient un code d'illustration]

    Bonjour Jipété,

    Sans avoir totalement résolu le problème, j'ai tout de même progressé .

    J'ai fait un dump de la description des images sur Windows et Linux Mint. Pour cela, j'ai déposé un TMemo baptisé mmo et utilisé Image1.Picture.Bitmap.RawImage.Description.Astring et bmp.RawImage.Description.AsString pour lire la description complète des bitmaps.
    Pour les deux, il y a une inversion des bits dans l'image de destination, mais ça ne perturbe en rien l'affichage.
    Surtout, avec Linux, tu obtiens automatiquement un BitsPerPixel de 32 (au lieu de 24), ce qui décale forcément toute l'image et expliquerait l'espace noir correspondant à exactement 1/4 de l'image (un octet tous les trois octets).

    Du coup, il suffit de tenir compte de ce quatrième octet pour obtenir une réplique parfaite. Voici un code (à visée pédagogique, car il peut être simplifié) qui montre l'opération :

    Code pascal : 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
    procedure TForm1.Button1Click(Sender: TObject);
    var
      w,h, wd, i: integer;
      work: array[0..2] of Byte;
      pbS,pbD: pByteArray;
      bmp: TBitmap;
      procedure Load(f: String);
      var
        Pict: TPicture;
      begin
        Pict := TPicture.Create;
        Pict.LoadFromFile(f);
        Image1.Picture.Assign(Pict);
        Pict.Free
      end;
    begin
      opd.InitialDir := Application.Location;
      if not opd.Execute then exit;
      load(opd.FileName);
      bmp := TBitmap.Create;
      bmp.PixelFormat := Image1.Picture.Bitmap.PixelFormat;
      bmp.Width  := Image1.Picture.Bitmap.Width;
      bmp.Height := Image1.Picture.Bitmap.Height;
     
      bmp.BeginUpdate();
     
      with Image1.Picture.Bitmap do
        for h := 0 to Height-1 do
        begin
          pbS := pByteArray(RawImage.GetLineStart(h));
          pbD := pByteArray(bmp.RawImage.GetLineStart(h));
     
          w := 0;
          wd := 0;
          while w < (Width*3)-1 do
          begin
            // paquet de 3 octets source
            for i := 0 to 2 do
            begin
              work[i] := pbS^[w];
              inc(w);
            end;
            // paquet de 4 octets destination
            pbD^[wd] := work[0];
            pbD^[wd + 1] := work[1];
            pbD^[wd + 2] := work[2];
            pbD^[wd + 3] := 0;
            inc(wd, 4);
          end;
          Caption := IntToStr(w);
        end;
      mmo.Append(Image1.Picture.Bitmap.RawImage.Description.AsString);
      mmo.Append(bmp.RawImage.Description.AsString);
     
      bmp.EndUpdate();
     
      image2.Picture.Bitmap.Assign(bmp);
      bmp.Free;
    end;

    Si l'expérience montre bien où est le problème, elle ne le résout qu'en partie : le code suppose qu'il s'agit d'une image en 24 bits transformée en 32 bits, ce qui nécessiterait bien sûr des tests (avec RawImage.Description).

    Bon dimanche !

    Gilles
    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

  10. #10
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Citation Envoyé par gvasseur58 Voir le message
    Si l'expérience montre bien où est le problème, elle ne le résout qu'en partie : le code suppose qu'il s'agit d'une image en 24 bits transformée en 32 bits, ce qui nécessiterait bien sûr des tests (avec RawImage.Description).
    Que je me refuse à employer,

    Voilà ce que j'ai constaté, au fil de nombreux essais.
    Ça vient d'une fonction perso OuvreImage(f: string): TBitmap; (d'où le RESULT) qui s'appuie sur une analyse du header du fichier passé.

    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
      // plus efficace pour ouvrir les fichiers parfois étranges (xbgr...)
      lii := TLazIntfImage.Create(0,0);
      try
        if OffsetToDatas = 54 then begin // synonyme de VersionHeader = 1
          lii.DataDescription := GetDescriptionFromDevice(0);
          lii.LoadFromFile(f);
        end else begin  // 70, 122 pour bgra, 138 pour xbgr, n/a pour jpg et d'autres encore
          OuvreFichier; // utilise TPicture pour l'assigner à RESULT -- c'est la proc "Load" du projet de test 
          with RESULT do
            lii.LoadFromBitmap(Handle, Handle, Width, Height); 
        end;
        RESULT.LoadFromIntfImage(lii); // renvoie un bitmap "bien" rempli
      finally
        lii.Free;
      end;
    On voit bien avec le test sur la version du header que les gens du TLazInftImage ont dû galérer également puisque selon cette version, il me faut changer la manière dont j'ouvre le fichier.
    Je vais donc tenter de l'implémenter dans le projet de test rapide "pour le fofo", qui va instantanément se transformer en usine à gaz (3 à 5 modules en plus, je ne sais pas exactement à l'heure où j'écris ces lignes).

    Ces quelques lignes d'adaptation sont également utilisées pour ouvrir le fichier d'entrée dans plein d'autres projets de tests, du coup à chaque fois il faut que je revoie tout ça, à chaque fois ça devient un machin à la Gaston Lagaffe inmaintenable, et quand j'y suis enfin (ou je crois y être) à chaque fois il y a quand même un dernier fichier qui décide de jouer la fille de l'air et me met tout en vrac...

    D'où mon désarroi, mon désespoir, et le temps qui fiche le camp...
    Parce que, mine de rien, les deux projets Delphi (dont l'un a tourné tip-top dans mon vieux Win2000 virtuel et son D7 perso au bout de 10 minutes environ), je les ai découverts il y a 3 semaines à peu près...
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Citation Envoyé par Jipété Voir le message
    Je vais donc tenter de l'implémenter dans le projet de test rapide "pour le fofo", qui va instantanément se transformer en usine à gaz (3 à 5 modules en plus, je ne sais pas exactement à l'heure où j'écris ces lignes).
    Bon voilà,

    J'ai trouvé une combine simple en 5 lignes pour m'éviter l'usine à gaz des 5 modules, et je remplace la procedure Load par une fonction funcload(f: string): TBitmap; dans laquelle j'intègre le code à base de TLazIntfImage pour améliorer l'ouverture des fichiers bizarres, et j'utilise une seconde fois ce code d'amélioration pour un affichage correct en sortie.

    Logiquement je devrais pouvoir accéder aux bytes qui m'intéressent.

    Ci-dessous le code du Button4, n'oubliez pas
    1. de n'utiliser que des bitmaps 32 bits (pas encore testé le comportement avec les 24 bits)
    2. de rajouter IntfGraphics dans les uses.


    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
    procedure TForm1.Button4Click(Sender: TObject);
    var
      src,dst: TBitmap;
      lii: TLazIntfImage;//http://wiki.freepascal.org/Developing_with_Graphics#TLazIntfImage.LoadFromFile
      function GetOffsetToDatas(b: TBitmap): integer;
      var
        bs: TBytesStream;
      begin
        bs := TBytesStream.Create;
        b.SaveToStream(bs);
        bs.Position:=10;
        GetOffsetToDatas := bs.ReadDWord;
        bs.Free;
      end;
      function funcload(f: String): TBitmap;
      var
        Pict: TPicture;
        lii: TLazIntfImage;
      begin
        Pict := TPicture.Create;
        Pict.LoadFromFile(f);
        //Image1.Picture.Assign(Pict); // raies en diagonale
     
        RESULT := TBitmap.Create;
        RESULT.PixelFormat:=pf32bit;
     
        lii := TLazIntfImage.Create(0,0);
        try
          //if OffsetToDatas = 54 then begin // synonyme de VersionHeader = 1
          if GetOffsetToDatas(Pict.bitmap) = 54 then begin
            lii.DataDescription := GetDescriptionFromDevice(0);
            lii.LoadFromFile(f);
          end else  // 70, 122 pour bgra, 138 pour xbgr, n/a pour jpg et d'autres encore
              lii.LoadFromBitmap(Pict.bitmap.Handle, Pict.bitmap.Handle, Pict.bitmap.Width, Pict.bitmap.Height);
     
          RESULT.LoadFromIntfImage(lii); // renvoie un bitmap "bien" rempli
        finally
          lii.Free;
        end;
        Pict.Free;
      end;
    begin
      opd.InitialDir := Application.Location;
      if not opd.Execute then exit;
     
      src := TBitmap.Create;
      src.PixelFormat := pf32bit;
      src := funcload(opd.FileName);
      image1.Picture.Bitmap.Assign(src); // témoin "avant"
     
      dst := TBitmap.Create;
      dst.PixelFormat := pf32bit;
      dst.Width  := Image1.Picture.Bitmap.Width;
      dst.Height := Image1.Picture.Bitmap.Height;
     
      // plus efficace pour ouvrir les fichiers parfois étranges (xbgr...)
      lii := TLazIntfImage.Create(0,0);
      try
        //if OffsetToDatas = 54 then begin // synonyme de VersionHeader = 1
        if GetOffsetToDatas(dst) = 54 then begin
          Caption := '54';
          lii.DataDescription := GetDescriptionFromDevice(0);
          lii.LoadFromFile(opd.FileName);
        end else  // 70, 122 pour bgra, 138 pour xbgr, n/a pour jpg et d'autres encore
            lii.LoadFromBitmap(dst.Handle, dst.Handle, dst.Width, dst.Height);
     
        image2.Picture.Bitmap.LoadFromIntfImage(lii); // renvoie un bitmap "bien" rempli pour le témoin "après"
      finally
        lii.Free;
      end;
      // ici les bytes corrects et "travaillables" devraient être dispo -- à tester...
      dst.Free;
      src.Free;
    end;
    Avec tout ça, j'ai essayé 6 fichiers différents, les raies en diagonale ont disparu et celui que Lazpaint n'ouvre pas éclot chez moi comme une fleur au printemps,

    Un dernier mot : j'ai pas mal parlé de VersionHeader, en fait cette chose n'existe pas, elle se déduit de la valeur trouvée à l'adresse 0Ahex (10dec) du header du fichier, section BitmapFileHeader, et se décode ainsi :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
        case BitmapFileHeader.biSize of
           12: Result.VersionHeader:=9; // perso : pour os/2
           40: Result.VersionHeader:=1;
           52: Result.VersionHeader:=2; // non documenté, utilisé par Adobe
           56: Result.VersionHeader:=3; // non documenté, utilisé par Adobe
          108: Result.VersionHeader:=4;
          124: Result.VersionHeader:=5;
          else Result.VersionHeader:=0;
        end;
    perso parce que ça n'existe pas dans la littérature officielle.
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  12. #12
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Citation Envoyé par Jipété Voir le message
    Logiquement je devrais pouvoir accéder aux bytes qui m'intéressent.
    Ça me démangeait, ça...
    J'ai donc testé, c'est plein de pièges.
    Bon, je dirais qu'à partir du moment où on le sait, on n'a qu'à faire attention et pi valà !
    Faut juste garder précieusement cette discussion et les codes associés, comme aide-mémoire.

    Regardez sur les images le mémo avec la valeur du PixelFormat du Bitmap associé au TImage, retrouvez-le dans le code des deux essais, et lisez bien le commentaire concernant l'inversion des bytes R et B : j'étais à des années-lumière d'imaginer ça, d'où mon texte "inversion pour jouer" sans penser une seule seconde que ça le serait sans le demander,
    essai 1 avec 2 lignes ajoutées au-dessus du bloc "lii"
    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
      image2.Picture.Bitmap.PixelFormat := pf32bit;
      memo1.Lines.Add('a-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
     
      // plus efficace pour ouvrir les fichiers parfois étranges (xbgr...)
      lii := TLazIntfImage.Create(0,0);
      try
        //if OffsetToDatas = 54 then begin // synonyme de VersionHeader = 1
        if GetOffsetToDatas(dst) = 54 then begin
          lii.DataDescription := GetDescriptionFromDevice(0);
          lii.LoadFromFile(opd.FileName);
        end else  // 70, 122 pour bgra, 138 pour xbgr, n/a pour jpg et d'autres encore
            lii.LoadFromBitmap(dst.Handle, dst.Handle, dst.Width, dst.Height);
     
        memo1.Lines.Add('b-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
        image2.Picture.Bitmap.LoadFromIntfImage(lii); // renvoie un bitmap "bien" rempli
      finally
        lii.Free;
      end;
      memo1.Lines.Add('c-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
     
      // ici les bytes corrects et "travaillables" devraient être dispo -- essai 1 ...
      memo1.Lines.Add('d-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
      image2.Picture.Bitmap.BeginUpdate();
      for h := 0 to image1.Picture.Bitmap.Height-1 do begin
        pbS := pByteArray(image1.Picture.Bitmap.RawImage.GetLineStart(h));
        pbD := pByteArray(image2.Picture.Bitmap.RawImage.GetLineStart(h));
        for w := 0 to (image1.Picture.Bitmap.Width*4)-1 do begin
          pbD^[w] := pbS^[w];
          if ((w + 1) mod 4 = 0) then begin // = traitement du 4e byte de la source terminé
            // R et B inversés pour jouer --> en fait ils sont naturellement inversés SI pf32bit
    {        tmpbyte := pbD^[w-3];
            pbD^[w-3] := pbD^[w-1];
            pbD^[w-1] := tmpbyte;      }
            // et transparence baissée
            pbD^[w] := 100; // sans effet -- fonctionne SI pf32bit
          end;
        end;
      end;
      image2.Picture.Bitmap.EndUpdate();
      memo1.Lines.Add('e-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
    Nom : essai1.png
Affichages : 98
Taille : 77,5 Ko

    ensuite avec l'essai 2, le bloc "lii" ne change pas et l'essai 1 est commenté :
    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
      // ici les bytes corrects et "travaillables" devraient être dispo -- essai 2 ...
      dst.BeginUpdate();
      for h := 0 to src.Height-1 do begin
        pbS := pByteArray(src.RawImage.GetLineStart(h));
        pbD := pByteArray(dst.RawImage.GetLineStart(h));
        for w := 0 to (src.Width*4)-1 do begin
          pbD^[w] := pbS^[w];
          if ((w + 1) mod 4 = 0) then begin // = traitement du 4e byte de la source terminé
            // R et B inversés pour jouer --> en fait ils sont naturellement inversés
    {        tmpbyte := pbD^[w-3];
            pbD^[w-3] := pbD^[w-1];
            pbD^[w-1] := tmpbyte;      }
            // et transparence baissée
            pbD^[w] := 100; // ok
          end;
        end;
      end;
      dst.EndUpdate();
      memo1.Lines.Add('d-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
      image2.Picture.Bitmap.Assign(dst);
      memo1.Lines.Add('e-'+IntToStr(BitsPerPixel(image2.Picture.Bitmap.PixelFormat)) + ' bpp');
      // repassé en 32 par l'assignation de dst
    Nom : essai2.png
Affichages : 98
Taille : 77,5 Ko
    Il n'y a qu'une différence entre ces deux images, c'est la ligne "d-"

    Normalement, à partir de là, je devrais pouvoir faire tout ce que je veux : à moi l'aventure !

    S'approcherait-on du ? Ah nan, faut encore que je teste tout ça avec des fichiers source en 24 bits...

    EDIT : pour le fun, un trackbar min 0 max 255 page 50 et un poil de code :
    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
    procedure TForm1.trkTranspChange(Sender: TObject);
    var
      w,h: integer;
      pbS,pbD: pByteArray;
    begin
      image2.Picture.Bitmap.BeginUpdate();
      for h := 0 to image1.Picture.Bitmap.Height-1 do begin
        pbS := pByteArray(image1.Picture.Bitmap.RawImage.GetLineStart(h));
        pbD := pByteArray(image2.Picture.Bitmap.RawImage.GetLineStart(h));
        for w := 0 to (image1.Picture.Bitmap.Width*4)-1 do begin
          pbD^[w] := pbS^[w];
          if ((w + 1) mod 4 = 0) then begin // = traitement du 4e byte de la source terminé
    {        // R et B inversés pour jouer --> en fait elles sont naturellement inversées SI pf32bit
            tmpbyte := pbD^[w-3];
            pbD^[w-3] := pbD^[w-1];
            pbD^[w-1] := tmpbyte;      }
            // et transparence baissée
            pbD^[w] := trkTransp.Position; // fonctionne SI pf32bit
          end;
        end;
      end;
      image2.Picture.Bitmap.EndUpdate();
    end;
    Nom : essaitrk.gif
Affichages : 107
Taille : 148,7 Ko

    Ah, désolé pour le bleu pourri, c'est le gif qui fait ça...
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  13. #13
    Membre émérite
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    septembre 2015
    Messages
    1 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Amateur Passionné
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : septembre 2015
    Messages : 1 087
    Points : 2 854
    Points
    2 854
    Billets dans le blog
    2

    Par défaut

    Bonjour,

    Ah ! ah ! ah ! toujours ce bon vieux problème avec le format BMP.

    Citation Envoyé par gvasseur58 Voir le message
    Bonjour Jipété,
    ....
    Pour ce qui est du format bmp (que j'ai abandonné parce qu'il n'offre pas de canal alpha),
    En fait non le BMP supporte très bien le canal alpha (BMP version 4 et 5) mais ce n'est pas sa spécificité par défaut)

    Le problème avec Lazarus/FPC et le format BMP est qu'il il y existe deux classes de chargement des fichiers BMP. Une dans FPC (FPReader) et une autre qui l'écrase dans la LCL (dans l'unit intfGraphic) L'un va pouvoir ouvrir certain BMP correctement et l'autre pas et inversement. Le problème avec les bitmaps c'est que le RawImageDescription est mal renseigné dans de nombreux cas avec le format BMP (ex un BMP 32bits sera chargé comme un 24bits. Mauvaise gestion du canal Alpha) De plus les classes de chargement de ce format BMP ne prend pas en compte correctement certaines spécificité du format BMP (gestion du bitbield, du canal alpha...) et dire que le format BMP est un des plus vieux
    Je rejoins Jipete c'est une vraie plaie de travaillé sur les bitmap avec les classes de base de FPC et Lazarus, il y a beaucoup d'incohérences et cela engendre des problèmes même dans l'affichage des composants visuels ou les erreurs sont corrigées avec des bouts de ficelles par moment. Bref

    Citation Envoyé par gvasseur58 Voir le message
    Personnellement, je préfère utiliser des bibliothèques comme BGRABitmap qui fonctionnent de manière moderne et efficace : plus rapides, plus polyvalentes (avec canal alpha et anticrénelage) et véritablement multiplateformes. Les outils standards de Lazarus le sont aussi tant qu'on essaye pas de sortir des techniques courantes.
    BGRABitmap est une très bonne bibliothèque c'est vrai mais elle ne corrige pas les erreurs de lecture du format BMP. En effet BGRABitmap s'appuie sur les routines de FPC/Lazarus (des corrections ont été faites pour le format TIFF mais pas BMP).
    Pour ma part je suis pas fan de la philosophie du traitement des bitmaps avec BGRABitmap (application des effets, transformation etc...)

    Plusieurs liens sur le forum en relation

    https://www.developpez.net/forums/d1...l-enfer-terre/
    https://www.developpez.net/forums/d1...-mode-pf32bit/
    https://www.developpez.net/forums/d1...-type-d-image/
    https://www.developpez.net/forums/d1...me-on-ne-sait/
    https://www.developpez.net/forums/d1...-bits-tbitmap/
    https://www.developpez.net/forums/d1...phisme-pointu/
    https://www.developpez.net/forums/d1...-fichiers-bmp/
    https://www.developpez.net/forums/d1...dage-bitfield/
    https://www.developpez.net/forums/d1...imale-d-image/
    https://www.developpez.net/forums/d1...ssible-ouvrir/

    [EDIT] + https://www.developpez.net/forums/d1...tlazintfimage/

    Bonne lecture

    A+
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  14. #14
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Salutàtoi !
    Citation Envoyé par BeanzMaster Voir le message
    Ah ! ah ! ah ! toujours ce bon vieux problème avec le format BMP.
    Bah, tant qu'il n'y aura pas quelqu'un qui prendra le taureau par les cornes, ça sera toujours du rafistolage à coups de morceaux de scotch et fil de fer, tu vois le truc ?

    Citation Envoyé par BeanzMaster Voir le message
    En fait non le BMP supporte très bien le canal alpha (BMP version 4 et 5) mais ce n'est pas sa spécificité par défaut)
    Je dirais même plus : on peut parfaitement utiliser une version 1 en déclarant pf32bits et en remplissant les 4 bytes, ça fonctionne. Ce qui est important, c'est la chose qui va ouvrir le fichier ensuite et traiter les datas qui s'y trouvent, c'est tout.

    Citation Envoyé par BeanzMaster Voir le message
    Je rejoins Jipete c'est une vraie plaie de travailler sur les bitmap avec les classes de base de FPC et Lazarus, il y a beaucoup d'incohérences et cela engendre des problèmes même dans l'affichage des composants visuels où les erreurs sont corrigées avec des bouts de ficelles par moment.
    Ça fait plaisir, je me sens moins seul.
    Bon là je fais une pause, j'en ai un peu marre.
    C'est toujours pareil : on torche 90 % du taf en un rien de temps, et les 10 % restants prennent des heures, des jours, des semaines...

    L'idée sur laquelle je bosse, ça serait une grosse boîte noire à qui je passerais un fichier 24 bits ou 32 bits et qui me cracherait en sortie un TBitmap 32 bits (je rappelle que j'ai besoin de bitmaps 32 bips pour faire tourner les progs Delphi que j'ai trouvés et qui sont bourrés de pRGBQuad pour faire leurs rééchantillonnages et autres interpolations).
    Fastoche, sur le papier, mais l'intérieur de la boîte ressemble à une locomotive de Dubout :

    Nom : loco_dubout.jpg
Affichages : 95
Taille : 47,7 Ko

    Merci pour la compil des posts, quel courage ! Je ne me sens pas le courage de me relire, d'autant plus qu'il se pourrait bien qu'il y ait des infos périmées, dépassées, erronées, alors bon, je préfère essayer de finir ma boîte noire...
    Gilles, je te réponds un peu plus tard.
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  15. #15
    Membre émérite
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    septembre 2015
    Messages
    1 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Amateur Passionné
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : septembre 2015
    Messages : 1 087
    Points : 2 854
    Points
    2 854
    Billets dans le blog
    2

    Par défaut

    Yop !

    Citation Envoyé par Jipété Voir le message
    Salut à toi !

    Bah, tant qu'il n'y aura pas quelqu'un qui prendra le taureau par les cornes, ça sera toujours du rafistolage à coups de morceaux de scotch et fil de fer, tu vois le truc ?
    Oui carrément, justement j'ai décidé que cette semaine j'allais me remettre en scelle et pour me motivé je vais re-plancher sur ma solution et mettre les sources à dispos

    Citation Envoyé par Jipété Voir le message
    Je dirais même plus : on peut parfaitement utiliser une version 1 en déclarant pf32bits et en remplissant les 4 bytes, ça fonctionne. Ce qui est important, c'est la chose qui va ouvrir le fichier ensuite et traiter les datas qui s'y trouvent, c'est tout.
    Tout à fait exacte

    Citation Envoyé par Jipété Voir le message
    Ça fait plaisir, je me sens moins seul.
    Bon là je fais une pause, j'en ai un peu marre.
    C'est toujours pareil : on torche 90 % du taf en un rien de temps, et les 10 % restants prennent des heures, des jours, des semaines...

    L'idée sur laquelle je bosse, ça serait une grosse boîte noire à qui je passerais un fichier 24 bits ou 32 bits et qui me cracherait en sortie un TBitmap 32 bits (je rappelle que j'ai besoin de bitmaps 32 bips pour faire tourner les progs Delphi que j'ai trouvés et qui sont bourrés de pRGBQuad pour faire leurs rééchantillonnages et autres interpolations).
    Fastoche, sur le papier, mais l'intérieur de la boîte ressemble à une locomotive de Dubout
    C'est d'ailleurs la raison qui m'avait poussé à coder ma solution et que je ne travail qu'avec des 32bits et c'est pour cela qu'avec des fichiers images en 16bits 24bits.... je fais directement la conversion vers du 32bits au chargements, c'est beaucoup plus facile et au moins pas de prise de tête lors de la manipulations des pixels.

    Citation Envoyé par Jipété Voir le message
    Merci pour la compil des posts, quel courage ! Je ne me sens pas le courage de me relire, d'autant plus qu'il se pourrait bien qu'il y ait des infos périmées, dépassées, erronées, alors bon, je préfère essayer de finir ma boîte noire...
    Gilles, je te réponds un peu plus tard.
    Non, non t'inquiètes les infos contenues dans tous ces postes ne sont pas périmées, erronées ou dépassées Dans tous ces sujets dans lesquels nous avons discuté, nous avons à chaque fois trouvé les solutions De plus il y a pas mal de petits bouts de code, de formules très intéressantes et qui fonctionnent !

    A bientôt
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  16. #16
    Modérateur
    Avatar de tourlourou
    Homme Profil pro
    Biologiste ; Progr(amateur)
    Inscrit en
    mars 2005
    Messages
    3 294
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Biologiste ; Progr(amateur)

    Informations forums :
    Inscription : mars 2005
    Messages : 3 294
    Points : 9 503
    Points
    9 503
    Billets dans le blog
    6

    Par défaut

    Je dirais même plus : on peut parfaitement utiliser une version 1 en déclarant pf32bits et en remplissant les 4 bytes, ça fonctionne. Ce qui est important, c'est la chose qui va ouvrir le fichier ensuite et traiter les datas qui s'y trouvent, c'est tout.
    Le problème n'est pas que ça fonctionne, mais qu'il faut que ça fonctionne comme c'est décrit dans le fichier, sans rien supposer. Il ne faut rien attendre d'autre.
    Les fichiers avec un format de stockage qui ne serait pas celui décrit (ou ne respectant pas une norme) sont mal formés. Le problème est donc de détecter automatiquement comment les rejeter ou les traiter différemment de ce qui est prévu en espérant en tirer quelque chose.... Et là, c'est forcément la misère !
    Delphi 5 Pro - Delphi 10.2 Tokyo Community Edition - CodeTyphon 6.50 sous Windows 10 ; CT 6.40 sous Ubuntu 18.04 (VM)
    . Ignorer la FAQ Delphi et les Cours et Tutoriels Delphi nuit gravement à notre code !

  17. #17
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Bonsoir, Yves
    Citation Envoyé par tourlourou Voir le message
    Le problème n'est pas que ça fonctionne, mais qu'il faut que ça fonctionne comme c'est décrit dans le fichier, sans rien supposer. Il ne faut rien attendre d'autre.
    Les fichiers avec un format de stockage qui ne serait pas celui décrit (ou ne respectant pas une norme) sont mal formés. Le problème est donc de détecter automatiquement comment les rejeter ou les traiter différemment de ce qui est prévu en espérant en tirer quelque chose.... Et là, c'est forcément la misère !
    D'accord avec toi, mais laisse-moi te conter l'aventure vécue suivante : à force de voir Léna en 400x300 jolie tout plein, je me suis dit qu'il fallait être plus vicieux, après tout, Gimp, Toshop et les autres autorisent ce que j'appelle des valeurs "exotiques" et j'ai donc concocté une Léna 397x299 et là, bim !
    En haut le témoin, et en bas le travail sans précautions :
    Nom : léna_kc.png
Affichages : 94
Taille : 67,2 Ko

    Il suffit pourtant de scrupuleusement suivre les informations dans le BitmapFileHeader et le BitmapInfoHeader pour retrouver sa peau de velours et ses yeux de biche mais je m'égare, là.

    Bon, allez, je retourne à ma boîte noire,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  18. #18
    Membre émérite
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    septembre 2015
    Messages
    1 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Amateur Passionné
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : septembre 2015
    Messages : 1 087
    Points : 2 854
    Points
    2 854
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Jipété Voir le message
    Bonsoir, Yves


    D'accord avec toi, mais laisse-moi te conter l'aventure vécue suivante : à force de voir Léna en 400x300 jolie tout plein, je me suis dit qu'il fallait être plus vicieux, après tout, Gimp, Toshop et les autres autorisent ce que j'appelle des valeurs "exotiques" et j'ai donc concocté une Léna 397x299 et là, bim !
    En haut le témoin, et en bas le travail sans précautions :
    Nom : léna_kc.png
Affichages : 94
Taille : 67,2 Ko

    Il suffit pourtant de scrupuleusement suivre les informations dans le BitmapFileHeader et le BitmapInfoHeader pour retrouver sa peau de velours et ses yeux de biche mais je m'égare, là.

    Bon, allez, je retourne à ma boîte noire,
    Salut ici avec ces dimensions je sens le padding de fin de ligne as tu vérifié cette valeur dans le RawImage.Description ?

    [EDIT peut-être une piste : https://www.developpez.net/forums/d1...-type-d-image/
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  19. #19
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Bonjour Jérôme,

    pour ne rien te cacher, je ne me souviens pas si la source est en 24 ou 32 bits, donc on passe sur ça, c'était juste pour l'ami Yves, lui illustrer les misères qu'on peut rencontrer, d'autant plus que j'ai un truc complètement hallucinant que je ne sais plus par quel bout prendre.

    Qu'on en juge : sur ce magnifique montage on a en fond la vue de l'éditeur hexadécimal ouvert sur un fichier de 3x2 en 24 bits, avec 3 pixels en surbrillance orange, ce sont les 3 qu'on voit juste dessous dans la maquette d'étude, la ligne du haut.
    Celle où se trouve le pointeur et qui est analysée par le colorpicker en bas à gauche, où l'on peut lire, en Delphi, FF 00 FF, ce qui correspond bien à ce qu'on voit dans l'éditeur hexa, pixel du centre.
    Nom : bug_du_183.png
Affichages : 83
Taille : 37,8 Ko

    Le gag c'est le log dans le mémo, à droite, où j'ai mis en surbrillance la valeur 183, dont je ne sais pas d'où elle sort puisqu'elle n'est pas dans le fichier.
    183dec c'est B7hex.
    Mais en attendant, ça décale tout ce qui suit et donc les couleurs en vrac sauf la 1re de chaque ligne…
    Le bleu clair de la seconde ligne c'est bien BF BF 7F, soit 191 191 127. Et le 183 de la 1re ligne à l'index 3 (1re colonne du mémo) correspond ici à la data 0, inexistante au milieu des datas de cette ligne (je ne compte pas le padding).


    Pour obtenir ces colonnes dans le mémo, rien de plus simple :
    (Les observateurs noteront que j'ai remplacé pByteArray par pByte, avec un résultat aussi nul.)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
      for h := 0 to src.Height-1 do begin
    //  pbS := pByte(src.RawImage.GetLineStart(h)); test avec dessous, résultat identique
        pbS := pByte(image1.Picture.Bitmap.RawImage.GetLineStart(h));
        for ws := 0 to (src.Width*3)-1 do memo1.Lines.Add(IntToStr(ws) +'  '+ IntToStr(pbS[ws]));
      end;
    C'est tout simplement ma boucle de copie où tout a été enlevé sauf la ligne de log, et je ne sais pas quoi ni où chercher.

    Une dernière précision : si, en fin de boucle, je demande à enregistrer le fichier source, bien sûr il n'y a pas de 183 dedans, ça serait trop facile sinon…

    Face à ça, à part un prêtre exorciseur spécialise du vaudou, je ne vois pas trop...
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  20. #20
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    juillet 2006
    Messages
    8 323
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : juillet 2006
    Messages : 8 323
    Points : 11 792
    Points
    11 792

    Par défaut

    Citation Envoyé par Jipété Voir le message
    Face à ça, à part un prêtre exorciseur spécialise du vaudou, je ne vois pas trop...
    Bon, pas de panique, je vais me débrouiller autrement (bidouilles, bidouilles, mais c'est pas un tas de ferraille avec un peu d'électronique dedans qui va me résister : quand on ne peut pas passer par devant, on passe par derrière, c'est bien connu, )

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
      mss := TMemoryStream.Create;
      src.SaveToStream(mss);
      mss.Position := 54; // pour test rapide -- à affiner
      for h := 0 to src.Height-1 do begin
        //memo1.Lines.Add(IntToStr(h)+'  '+IntToStr(src.Width*3));
        for ws := 0 to (src.Width*3)-1 do
          memo1.Lines.Add(IntToStr(ws)+'  '+IntToStr(mss.ReadByte));
        // attention, le stream embarque le padding, méfi !
        p := 0; // ok pour skipper les bytes de padding
        while (((src.Width*3)+p) mod 4 <> 0) do begin mss.ReadByte; inc(p); end;
      end;
      mss.Free;
    Et avec ça, plus de 183 qui traîne dans le mémo,
    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
    0  191
    1  191
    2  127
    3  127
    4  191
    5  191
    6  191
    7  127
    8  191
    0  0
    1  139
    2  255
    3  255
    4  0
    5  255
    6  128
    7  128
    8  0
    Juste faire gaffe que les lignes sont à l'envers par rapport à l'affichage dans le TImage, mais bon.

    C'est mardi, ch'suis à la bourre, pas le temps de tester les couleurs mais le coup du stream ça me démangeait pour virer ce 183 (dont au final je ne saurai pas d'où il vient), donc voilà.

    À pluche,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 10 12345 ... DernièreDernière

Discussions similaires

  1. Déplacer des fichiers Excel sous Windows avec SAS
    Par Antoun dans le forum Outils BI
    Réponses: 6
    Dernier message: 19/11/2009, 17h05
  2. [Vxi] liens avec des fichiers .jpg, bmp, ou gif
    Par chendo dans le forum Designer
    Réponses: 1
    Dernier message: 14/10/2009, 09h48
  3. Gestion des fichiers users sous linux
    Par darkvodka dans le forum C++
    Réponses: 2
    Dernier message: 29/09/2007, 19h04
  4. Créer et utiliser des fichiers excel sous linux
    Par cronos6 dans le forum Zope
    Réponses: 2
    Dernier message: 02/06/2006, 09h14
  5. Lire des fichiers iso sous linux
    Par wodel dans le forum Applications et environnements graphiques
    Réponses: 3
    Dernier message: 28/11/2005, 10h17

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