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 :

Une info pour ceux qui font du graphisme pointu


Sujet :

Lazarus Pascal

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bout de code dans une procédure et utilisation d'une image pf32bit :
    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
      Case img.Picture.Bitmap.PixelFormat of
        pf24bit: TmpStr:='24 Bits';
        pf32bit: TmpStr:='32 Bits';
        pfDevice: TmpStr:='Device';
      end;
      Label2.Caption:='Format2 de l''image : '+TmpStr;
     
      img.Picture.Bitmap.Canvas.Draw(10,10,Bmp);// déplacement 10 10 juste pour voir si ça fonctionne -> ok
     
      Case img.Picture.Bitmap.PixelFormat of
        pf24bit: TmpStr:='24 Bits';
        pf32bit: TmpStr:='32 Bits';
        pfDevice: TmpStr:='Device';
      end;
      Label3.Caption:='Format3 de l''image : '+TmpStr;
    Au premier appel de la procédure qui contient ce bout de code, je récupère
    Format2 de l'image : 32 Bits
    Format3 de l'image : 32 Bits
    et au second appel, alors que rien n'est changé et que le Bmp.PixelFormat est toujours à pf32bit au milieu du bout de code (vérifié, pas mis pour pas alourdir) :
    Format2 de l'image : 32 Bits
    Format3 de l'image : 24 Bits
    J'abandonne, c'est épuisant, et je ne compte pas les heures perdues...

    Joyeux Noël quand même.

    EDIT : je barre les résultats, car ça vient du fichier...
    Pour avoir ce résultat bizarre et variable, je suis parti du img.png trouvable dans le .zip de Pierre dans sa discussion, 4e post
    Ensuite j'ai créé moi aussi un png (avec Gimp, copie d'écran quelconque, clic droit "ajouter un canal Alpha", exporter en png et voilà, 32 bits).
    Et 32 bits qui restent quelque que soit le nombre de passages dans le bout de proc.

    Maintenant, la bonne question c'est : qu'est-ce que c'est dans le fichier de Pierre (et le mien, joliment renommé caca.bmp par mm_71, ) qui peut à ce point perturber la copie img.Picture.Bitmap.Canvas.Draw(10,10,Bmp); à tel point que le PixelFormat en soit changé ?
    Bonne question, je passe...
    J'ai préparé un zip pour ceux qui aiment jouer (code et fichiers image) : pixelformat.7z

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonjour,

    je n'ai rien bu de chargé pour Noël, et j'en ai profité pour (essayer de) tester la librairie Graphics32, qui s'installe dans Linux mais dont 2 composants sont totalement inutilisables (ça plante l'EDI quand j'essaye de les poser sur une fiche !) : les 2 en rapport avec Img...
    De la même manière, impossible d'ouvrir la majorité des exemples, même cause (inconnue, car la fenêtre du message d'erreur est vide...) même effet -- je sens que Graphics32 va finir à la poubelle, hélas...
    Nom : gr32_polygons_exemple.png
Affichages : 308
Taille : 45,2 Ko

    (on voit bien que l'EDI est complètement planté : j'ai déplacé la fenêtre vide, la fenêtre de l'éditeur de code n'a pas été rafraîchie).
    Dommage, le peu d'exemples qui compilaient avaient l'air intéressant (magnifique GradLines )...

    Ensuite j'ai testé l'autre librairie célèbre, j'ai nommé la Vampyre !
    C'était prometteur, j'avais lu sur un site que la dernière mouture avait été testée sous Linux et que tout allait bien. Fallait juste le dire vite ! Car pour compiler leur exemple LCL Imager, il a quand même fallu remplacer ligne 339 de ImagingComponents.pas
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
      {$IF Defined(LCLGTK2)}
        GLib2, GDK2, GTK2, GTKDef, GTKProc,
    par
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
      {$IF Defined(LCLGTK2)}
        GLib2, GDK2, GTK2, GTK2Def, GTK2Proc,
    et TGtkDeviceContext(Dest).Offset; par TGtk2DeviceContext(Dest).Offset; lignes 778 et 781.
    Bref...

    Et une fois ce LCL Imager opérationnel, j'ai malheureusement constaté ceci :
    Sur la même machine,
    dans la même session,
    deux programmes avec le même dialogue TOpenPictureDialog
    qui sélectionne le même fichier dans la liste proposée par cet OPD
    dans le même dossier accédé en dur (pas de lien),
    à gauche la preview de l'OPD depuis un de mes programmes de test, et à droite la preview de l'OPD dans ce LCL Imager fraîchement compilé :
    Nom : caca.bmp.png
Affichages : 311
Taille : 51,2 Ko
    On pourrait croire que tout va bien (Vampyre pourrait solutionner mon problème d'ouverture de ce fichier, indépendamment du fait qu'on ne sait pas pourquoi et comment l'OPD se comporte différemment [et ça c'est le plus fou -- pour moi]), mais voilà comment ça se passe avec un autre fichier :

    Nom : lab-compose.bmp.png
Affichages : 301
Taille : 58,9 Ko

    Le plus dément c'est qu'il n'y a rien pour tripatouiler le code de la boîte de dialogue dans le corps des programmes, et les propriétés dans l'inspecteur d'objets sont identiques (à part FileMustExists et AutoPreview qui sont à True dans Vampyre)...

    Et bien sûr, l'aide de Lazarus est égale à elle-même...
    Voilà ce que je gagne quand je clique sur le lien en bas à gauche :
    Nom : bug_openoptions.png
Affichages : 302
Taille : 139,7 Ko

    Je me demande bien pourquoi ils nous mettent ce baratin et ce lien dans la case jaune ; ils les testent, leurs trucs ?

  3. #83
    Expert confirmé
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    Septembre 2015
    Messages
    1 899
    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 899
    Points : 4 353
    Points
    4 353
    Billets dans le blog
    2
    Par défaut
    Bonjour à tous et Joyeux Noël,

    rolala j'en ai raté des choses. Bon faisons simple.

    Pour les Images Tiff, FPC ne supporte pas tous les formats et de loin. Pour gérer plus de format on pour passer pas la librairie GraphicEx (https://github.com/mike-lischke/GraphicEx) mais j'ai pas testé

    Pour la transparence, et ce FondRVB.Bmp voila un petit projet de test avec les "FastBitmap/FastImage" : PictureIt.zip
    J'ai testé sous Windows, MV Linux Mint, MV Debian et le tout en 64bit

    Affichage de OpenPictureDialog
    Nom : OPDPictureIt.jpg
Affichages : 293
Taille : 45,5 Ko

    Affichage dans le programme de test
    Nom : PictureitFondRvb.jpg
Affichages : 290
Taille : 41,3 Ko

    Test de la transparence
    Nom : pictureitalpha.jpg
Affichages : 322
Taille : 56,5 Ko

    Voila je laisse joué un peux avec.
    Un truc bizarre sous Linux lorsque l'on clique sur le bouton capturer l'ecran les couleurs R et B sont inversées et si on clique une 2eme fois tout redevient correct.
    Et aussi il y a encore quelques bugs d'affichage selon les fonctions du DrawMode et AlphaMode avec le test "ColorMix" je vous laisse tester en cliquant sur les différents boutons

    Vous pouvez également déplacer le bitmap dans le "TImage" en appuyant sur CTRL+et maintenant enfoncé le Bouton gauche de la souris.
    Pour zoomer par pas de 5% servez vous de la molette et si vous appuyez sur CTRL le pas sera de 1%

    Sinon j'ai pas mal modifié le Projet de Benchmark, je ferai un zip quand j'aurais corrigé quelques bugs

    Nom : beanzbenchmark.jpg
Affichages : 306
Taille : 110,0 Ko

    Pour GR32 j'ai essayé aussi, je l'ai enlevé, car à chaque fois que j'ai besoins de reconstruire l'edi j'ai une erreur Crc avec le fichier gr32_blend sous windows

    Voila amusez vous bien

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Citation Envoyé par BeanzMaster Voir le message
    Pour gérer plus de format on pour passer pas la librairie GraphicEx (https://github.com/mike-lischke/GraphicEx) mais j'ai pas testé
    J'ai suivi ton lien, je suis allé voir sur le site d'origine, il semblerait que ce projet soit orienté Delphi pur et dur alors même pas j'essaye...

    Citation Envoyé par BeanzMaster Voir le message
    Pour la transparence, et ce FondRVB.Bmp voila un petit projet de test avec les "FastBitmap/FastImage" : PictureIt.zip
    J'ai testé sous Windows, MV Linux Mint, MV Debian et le tout en 64bit
    [...]
    Voila amusez-vous bien
    Et moi en 32 bits je ne compile pas, donc l'amusement aura été de très courte durée...

    Nom : erreur_bzsystem.png
Affichages : 291
Taille : 17,1 Ko

  5. #85
    Expert confirmé
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    Septembre 2015
    Messages
    1 899
    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 899
    Points : 4 353
    Points
    4 353
    Billets dans le blog
    2
    Par défaut
    Essayes juste de viré les trois procedure en assembleur au dessus sinon encadre les avec {$IFNDEF NO_ASM_OPTIMISATIONS}...{$ENDIF} sinon prend juste la function FixPathDelimiter(Path); et colle la dans BZBitmap.pas et vire BZSystem de la clause uses

    Pour GraphicEx elle est compatible avec FPC y'a tout un tas de {$ifde FPC} par contre pas sur qu'elle marche aussi bien que sous Delphi

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Citation Envoyé par BeanzMaster Voir le message
    Essayes juste de virer les trois procedure en assembleur au dessus sinon encadre-les avec {$IFNDEF NO_ASM_OPTIMISATIONS}...{$ENDIF} sinon prend juste la function FixPathDelimiter(Path); et colle-la dans BZBitmap.pas et vire BZSystem de la clause uses
    Je les ai commentées, tes 3 procs, ça ne suffisait pas, j'ai donc recopié ton FixPathDelimiter ça l'a fait. Je trouve cependant ça un peu lourd, juste pour faire des tests.

    'fin bon, de toute façon tu t'appuies sur FPImage qui n'est pas fini, donc par exemple le fichier CIE L*a*b* s'ouvre en noir et blanc, comme montré dans ce post (image du haut de la colonne centrale)...
    Par ailleurs FPImage ne sait pas ouvrir les .TIFF compressés en LZW, donc toi non plus


    Citation Envoyé par BeanzMaster Voir le message
    Pour GraphicEx elle est compatible avec FPC y'a tout un tas de {$ifdef FPC} par contre pas sur qu'elle marche aussi bien que sous Delphi
    Pour GraphicEx, ce n'est pas parce qu'il y a un tas de {$ifdef fpc} que c'est compatible, car j'ai essayé de compiler un projet du dossier "Demos" (le "OneImage", il avait l'air facile) et bien sûr ça a échoué, avec des trucs du genre (dans proj_common.pas)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    {$IFNDEF FPC}
      Windows,
    {$ELSE}
      LCLIntf, LCLType, LMessages,
    {$ENDIF}
      Math, SysUtils, {ShlObj, ActiveX,} Forms;
    et ils ont complètement zappé que les deux unités en commentaire ci-dessus n'étaient pas commentées à l'origine, or elles sont typiquement Windows mais pas protégées par le {$IFNDEF FPC} ...

    Une fois commentées ça coince ailleurs, dans une autre unité (TIFF.pas) :


    Allez, poubelle, GraphicEx, dommage, vu la quantité de fichiers image divers et variés, on peut supposer qu'il y avait du grain à moudre. Mais je n'ai pas les meules qui vont bien...

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Citation Envoyé par BeanzMaster Voir le message
    Pour GR32 j'ai essayé aussi, je l'ai enlevé, car à chaque fois que j'ai besoins de reconstruire l'edi j'ai une erreur Crc avec le fichier gr32_blend sous windows
    Une erreur CRC en général c'est une erreur hardware, et plus particulièrement une erreur au niveau du média : disquette (erreur courante et commune à l'époque), disque dur, etc., et à un endroit de la surface il y a un défaut d'où l'erreur.
    Tu devrais faire une sauvegarde de ton disque et un test approfondi derrière.

    Car en ce qui me concerne, dans une machine virtuelle aucun problème de ce genre (juste un pb débile dans ByteMaps/MainUnit.pas :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
        {$IFDEF FPC}
        CoolBar: TCoolBar;
        {$ELSE}
        CoolBar: TToolBar;
        {$ENDIF}
    il a fallu que j'inverse les 2 lignes Coolbar: pour que je puisse lancer l'exe (pas testé sous Delphi, j'ai plus ça sous la main facilement).

    Bon, bien sûr ce compo s'appuie sur FPImage donc le moindre problème dans un fichier et paf !, le truc en vrac, donc poubelle aussi mais c'est vraiment dommage.

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonjour,

    je crois que j'ai enfin réussi à déboucher de l'autre côté du tunnel, que je pensais sans fin,

    À l'inverse de l'ami Jérôme et son usine à gaz (mais ce n'est pas un reproche, il faut des usines à gaz pour alimenter les habitants des grandes villes), en ce qui me concerne et n'ayant qu'un petit besoin limité à quelque chose de précis, je me suis dit qu'un simple campingaz posé sur trois pierres ça le ferait (à condition de bien le caler, pas qu'il fiche le feu à la forêt, ).

    J'ai testé le code qui suit avec les deux unités "Mitchell", savoir CompImages.pas & LCLCompImages.pas et les quelques lignes ci-après.

    Pour le mettre en œuvre, il faut un bouton, un TImage, une case à cocher accessoire, un TMemo accessoire aussi, et une OpenPictureDialog, that's all, folks !

    Tout est là, et cette chose a pu ouvrir tous mes bmp 24 et 32 bits, même celui que LazPaint n'ouvre pas...

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    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
    84
    85
    procedure TForm1.Button1Click(Sender: TObject);
    var
      Start:  DWORD;
      bmp: TBitmap;
      p: pRGBQuad;
      OffsetToDatas, VersionHeader, biBitCount: integer;
     
      function GetVersionHeader(biSize: integer): integer;
      begin 
        case biSize of
           12: Result:=9; // perso : pour os/2
           40: Result:=1;
           52: Result:=2; // non documenté, utilisé par Adobe
           56: Result:=3; // non documenté, utilisé par Adobe
          108: Result:=4;
          124: Result:=5;
          else Result:=0;
        end;
      end;
     
      procedure GetHeaderInfos(f: string; b: TBitmap);
      var
        bs: TBytesStream;
      begin
        bs := TBytesStream.Create;
        if b = nil then bs.LoadFromFile(f);
        if f = ''  then b.SaveToStream(bs);
        bs.Position   := 10; // bfOffBits  @0A
        OffsetToDatas := bs.ReadDWord;
        bs.Position   := 14; // biSize     @0E
        VersionHeader := GetVersionHeader(bs.ReadDWord);
        bs.Position   := 28; // biBitCount @1C
        biBitCount    := bs.ReadWord;
        bs.Free;
      end;
     
      procedure WorkWithMitchell(Filename: String);
      var
        w,h: Integer;
      begin
        ci := TCompactImage.Create(0,0);
        ci.LoadFromFile(FileName);
        with img do begin
          Picture := nil;
          Width := ci.Width;
          Height:= ci.Height;
        end;
        lclci := TLCLCompactImage.Create(ci); // Update des dimensions inclus dans le Create
        //Memo1.Text:=lclci.Description;
        GetHeaderInfos(filename, nil);
        bmp:=TBitmap.Create;
        with bmp do begin
          //PixelFormat et dimensions inutiles, positionnés par Assign
          Assign(lclci.ImageBitmap);
          if biBitCount = 32 then begin // +1 et PAS PixelFormat qui est tjrs à 32 !
            BeginUpdate();
            for h := 0 to Height-1 do begin
              p := pRGBQuad(RawImage.GetLineStart(h));
              for w := 0 to Width-1 do begin 
                if p[w].rgbReserved = 0
                then p[w].rgbReserved := 255
                else if (p[w].rgbReserved < 255) then p[w].rgbReserved := 255-p[w].rgbReserved;
                // < 255 car si 00 dans le fichier alors Mitchell inverse à 255. Des heures là-dessus...
              end;
            end; //for h
            EndUpdate();
          end; //if BC
          if ckbxSave.Checked then SaveToFile('/chemin/test.bmp');
        end; //with bmp
        img.Picture.Bitmap.Assign(bmp);
     
        if ckbxShowInfos.Checked then
          Memo1.Text:=StringReplace(img.Picture.Bitmap.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll]);
        bmp.Free;
        lclci.Free;
        ci.Free;
      end;
     
    begin
      if opd.Execute then begin
        Start := GetTickCount;
        WorkWithMitchell(opd.Filename);
        Caption := IntToStr(GetTickCount-Start) + ' millisec';
      end;
    end;
    Voilà,
    Merci de tester et de me dire -- attention, il n'y a aucun contrôle sur la validité des fichiers passés, à vous de gérer correctement vos trucs.

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

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

    Informations forums :
    Inscription : Mars 2005
    Messages : 3 886
    Points : 11 409
    Points
    11 409
    Billets dans le blog
    6
    Par défaut
    Bonjour JP, je suis désolé, mais je n'ai pas trouvé d'unité LCLCompImages.pas sur le net... J'ai trouvé CompImages.pas ici, mais pas l'autre !
    Si tu peux les fournir...

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonour, Yves,
    Citation Envoyé par tourlourou Voir le message
    Bonjour JP, je suis désolé, mais je n'ai pas trouvé d'unité LCLCompImages.pas sur le net... J'ai trouvé CompImages.pas ici, mais pas l'autre !
    C'est parce que tu n'as pas bien lu les instructions,

    Citation Envoyé par Jipété Voir le message
    Ce projet est discuté là (ah ben vi, tout en english mais c'est pas trop compliqué et c'est vite lu), quand vous avez fini de lire vous remontez tout en haut il y a un lien "next" à droite qui vous emmènera vers la 2e partie, puis deux fois "next" pour atteindre la 3e et dernière partie où se trouve un lien github pour récupérer un zip.
    Update : trois fois, maintenant, pour atteindre la 3e partie de l'étude.

    Je t'épargne des souffrances (d'autant plus que c'est très mal fichu pour naviguer sur ce github, et je n'y ai pas trouvé le zip dont je parlais en 2016 -- par contre ce lien pointe sur le projet complet).

    Une fois sur la page affichant les sources du projet "test", il faut cliquer sur chaque fichier puis sur "raw" en haut à droite et enfin "Fichier / Enregistrer sous..." puis une fois le fichier enregistré, deux fois retour page précédente dans le navigateur et fichier suivant. Une misère...

    Si tu ne veux pas t'embêter à télécharger tous les fichiers du dossier FreeType, tu peux commenter CompFonts dans le uses du Main.pas, tu compiles, il va y avoir quelques lignes à commenter et voilà .
    Tu feras attention, l'exe est enregistré au niveau supérieur () à cause de Projet / Options / Chemins / Nom du fichier cible qui contient "../Test" et j'ai viré "../".

    Enfin, tu peux aussi ne récupérer que le fichier qui t'intéresse,

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

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

    Informations forums :
    Inscription : Mars 2005
    Messages : 3 886
    Points : 11 409
    Points
    11 409
    Billets dans le blog
    6
    Par défaut
    OK, merci. Le test échoue avec CT6.5 sous Win10 64 Bits (image en N&B) pour le fichier de carrés colorés nommé 512x128x32.bmp (celui x16 itou, mais celui x24 OK).

    [EDIT] Au moins, même résultat sous CT6.4 sous Ubuntu18.04 64 Bits.

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Citation Envoyé par tourlourou Voir le message
    OK, merci. Le test échoue avec CT6.5 sous Win10 64 Bits (image en N&B) pour le fichier de carrés colorés nommé 512x128x32.bmp (celui x16 itou, mais celui x24 OK).

    [EDIT] Au moins, même résultat sous CT6.4 sous Ubuntu18.04 64 Bits.
    Idem avec mon vieux Debian 32 bits...

    Nom : erreur_bmp.png
Affichages : 288
Taille : 10,3 Ko

    Par contre Gimp l'ouvre

    EDIT : C'est curieux que Gimp arrive à l'ouvrir (couteau suisse, cet outil ?), parce que j'ai fait ça :
    une fois ouvert,
    - je le réexporte en changeant le nom et en forçant le mode XRGB dans les options d'export, ce qui va lui conserver le mode bi_BITFIELDS (03 @ 1E, comme l'original) et là Linux l'ouvre bien, mais pas l'outil à base des .pas Mitchell dont j'ai bien l'impression qu'il ne supporte pas ce type de fichiers.
    Fichier dont le header est bizarre : 38 @ 0E donne 56: Result:=3; // non documenté, utilisé par Adobe dans la moulinette GetVersionHeader.

    - et si je rajoute un canal alpha et que j'ai donc un vrai 32 bits, alors là aucun problème (le fichier grossit de 52 bytes environ).

    cadeau : 4fic_512x128x32_gimp.bmp.zip

  13. #93
    Expert confirmé
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    Septembre 2015
    Messages
    1 899
    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 899
    Points : 4 353
    Points
    4 353
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Jipété Voir le message
    Idem avec mon vieux Debian 32 bits...

    Nom : erreur_bmp.png
Affichages : 288
Taille : 10,3 Ko

    Par contre Gimp l'ouvre
    Oye ! Oye ! je suis moins présent depuis quelques jour (je fais un remplacement dans un resto)

    Lazarus, lui devrais l'ouvrir et oui j'ai eu le temp de faire quelques tests avec ma liste de bmp (Merci Yves pour tes tests et tes fichiers de resultats. Voici le mien avec un TImage et les méthodes de Lazarus : OpenBmpTestResults TImage.txt ) Au final Lazarus s'en sort plus tôt pas trop mal en ce qui concerne le chargement des fichiers BMP (il lit même les mauvais bmp "headersize") Pourquoi ? tout simplement par ce qu'il ne teste pas la propriété "HeaderSize" de l'en-tête. Dès le départ il considère que se sont tous des BMP Version 1.0. S'en suit un petit calcul pour récupérer la palette si il y en a une. Ensuite il teste plus loin cette valeur (C'est Jipete qu'il me l'avais fais remarqué dans l'autre post). je corrigerai le TBMPView dans ce sens dès que j'aurais un peu plus de temps libre

    LE GROS PROBLEME vient de la gestion interne de se satané TRawImage. Je m'explique si le TImage a sa propriété "Transparent" à false alors tout va bien (sauf pour certains fichiers 32bits v4/v5 erreur avec le BitField et les masque RGBA) Mais dès que l'on passe la propriété "Transparent" du TImage à TRUE alors là c'est la cata, des fichiers 24bits se voient affublées d'un canal alpha (cf résultat de ma copie d'ecran) Il y a sérieusement de gros soucis avec les conversions 24bits --> 32bits (et inversement).

    [EDIT] Tes 4 derniers fichiers BMP s'affichent impeccable avec TBMPViewer

  14. #94
    Membre éprouvé Avatar de der§en
    Homme Profil pro
    Chambord
    Inscrit en
    Septembre 2005
    Messages
    879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : Chambord
    Secteur : Transports

    Informations forums :
    Inscription : Septembre 2005
    Messages : 879
    Points : 1 257
    Points
    1 257
    Par défaut
    Petit apparté : ces discussions sur ces pb sont trés intéressant en ce qui me concerne, merci aux participants pour tout ce que j’y apprend…

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonjour,

    ayant eu récemment l'occasion de comparer le rendu de filtres identiques utilisés pour l'agrandissement d'images, je tenais à partager mon expérience.

    Car si les noms des filtres sont les mêmes (je n'ai fait que deux copies d'écran, mais c'est pareil pour d'autres), leurs mises en œuvre et donc leurs rendus sont bien différents.

    Qu'on en juge avec à gauche du pur FreePascal (v 2.6.2, je sais je sais...) dans son jus et à droite l'utilisation de la version 1.03 de l'unité Resample d'Anders Melander.

    D'abord le filtre Mitchell :

    Nom : comparMitchell.jpg
Affichages : 171
Taille : 84,7 Ko

    et ensuite le Lanczos :

    Nom : comparLanczos.jpg
Affichages : 183
Taille : 90,7 Ko

    Il s'agit de l'agrandissement à 200 % d'une image de 240 x 180, pas comme si j'avais demandé 197 % sur une 253 x 179, vous voyez le truc ?
    Vous noterez qu'à dimensions strictement identiques de ces copies d'écran, la compression jpeg génère un fichier de presque 87 ko pour le Mitchell et de presque 93 pour l'autre : la matière est donc bien différente de l'un à l'autre.
    Bon, je ne sais pas vous, mais moi, dans les deux cas je préfère la version Melander.

    Et j'ai un soupçon d'explication : le code pour le premier pèse 110 lignes, contre 350 pour le second, qui doit surement faire des choses que le premier zappe.

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonsoir,

    une autre info :

    ça faisait un bout de temps que j'avais cette note dans un dossier, me promettant de la tester un jour :
    If you are reducing the image, resize it horizontally first. If you are enlarging the image, resize it vertically first.
    source : Quelque part chez

    Ben ce jour c'était aujourd'hui.

    D'abord une petite démo de l'outil utilisé pour mettre les différences en évidence :
    1re image, un original ;
    2e image, la même mais avec une différence, le M rouge ;
    3e image, la différence entre les deux, et je les inscris sur un fond noir, en inversant les bytes différents avec diff_byte := 255 - byte_from_2nd_fichier; (bon, je n'ai pas encore cherché pourquoi un rouge inversé s'affiche en bleu, je verrai ça plus tard, le principal était de localiser les différences).

    Nom : democompar.gif
Affichages : 168
Taille : 118,5 Ko

    Ensuite j'ai pris la même image source que pour le gif, l'ai ouverte avec mon Gimp, lui ai appliqué un redimensionnement x 8 en deux temps (en haut à gauche, d'abord la hauteur, en ayant bien pris soin de décocher "conserver le ratio", puis la largeur), ensuite j'ai refait la manip avec un seul redimensionnement complet h + l en un seul passage (en bas à gauche), et comme un examen minutieux à l'œil ne mettait rien en évidence, j'ai fait tourner le comparateur, résultat en haut à droite (en bas à droite l'image originale).

    Nom : compar_agrandiss.jpg
Affichages : 163
Taille : 168,0 Ko

    Tous les points de couleur (presque 5 millions sur 48 au total) indiquent donc des pixels où un (ou des) byte(s) diffère(nt) entre les deux manières d'agrandir une image.

    J'ai vérifié à l'éditeur hexa et j'ai compris pourquoi on ne voit pas ces différences relevées par le programme : on peut avoir quelque part un rouge à 255 0 0 avec une manière et à 254 0 0 (ou 255 1 0) avec l'autre manière : différences invisibles à l'œil nu.
    Une curiosité : le damier au-dessus de l'avion est strictement identique.

    Je ne sais pas si c'est utile, peut-être que oui selon le sujet à agrandir, en tout cas, c'est toujours bon à savoir.
    Une dernière petite animation pour la route : le 1er chevron jaune sur fond bleu foncé, à gauche de "Couleur opposée" :
    (je ne sais plus qui est qui, )
    Nom : chevron.gif
Affichages : 177
Taille : 12,2 Ko

    Des images de rotations curieuses à examiner en fin de ce pdf (plein de formules mathématiques horribles ).

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonjour,

    ça me démangeait, alors ce matin à la fraîche, les idées claires, j'ai pondu ça viteuf' :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
        // bs1,2,3 sont des TBytesStream et b est un byte
        for w := 0 to LineSize-1 do begin
          if bs1.ReadByte <> bs2.ReadByte then begin // copie != original
            bs2.Position := bs2.Position-1; // reculer de 1 car le ReadByte fait avancer automatiq.
            b := bs2.ReadByte; // récupérer le byte différent
            if b < 128 then b := b+128 else if b > 127 then b := b-127; // le modifier
            bs3.Position := bs2.Position-1; // se mettre au bon endroit dans le fichier "diff"
            bs3.WriteByte(b); // écrire le byte différent
            inc(CompteurDeDiff);
            Different := True;
          end;
        end;
    et ça donne ça (pour le M rouge du gif, il devient un M gris) :

    Nom : diffs.jpg
Affichages : 164
Taille : 117,5 Ko

    Et maintenant j'hésite : je me dis qu'au final, est-ce bien la peine d'inverser ?
    Comparons avec le résultat obtenu lorsque la ligne 6 est commentée :

    Nom : diffs_wo_corr.jpg
Affichages : 159
Taille : 109,2 Ko

    C'est pas mal du tout mais, dans l'absolu, s'il s'agit de repérer des différences dans des gris sombres dans une image globalement sombre alors que le fond (le "support") est déjà noir, pas sûr que ça se verra.
    Me faudrait une case à cocher (et générer deux fichiers pour gagner du temps) pour passer de l'un à l'autre.
    Quelqu'un aurait un avis là-dessus ?

    Vous allez me dire : y a qu'à pas mettre de fond noir (et donc "support" blanc). D'accord, mais le problème se reposera avec une image où il y a beaucoup de blanc, par exemple une photo de paysage avec le ciel bien surex', bien cramé, irrattrapable.

    Bon, c'est à réfléchir.
    - - -

    J'ai regénéré les fichiers d'hier en x4 seulement et j'en ai profité pour tester avec les autres manières de faire, résultat :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    manière | résultat
    _aucune | fichiers identiques
    cubique | 1 840 494 px diff
    lanczos | 5 448 923 px diff
    linéair | 1 128 564 px diff
    fullfic | 7 680 122 px, pour info
    Et pendant que j'y étais, j'ai regardé de près le damier, résultat, attention avec Lanczos et ses artefacts !
    Nom : compar3resize.jpg
Affichages : 158
Taille : 60,1 Ko

    d'autant plus que cet algo se permet de modifier la transparence dans les fichiers 32 bits, chose que je n'admets pas !

    En haut la source, FF -> pas de transparence
    Dessous, la transparence commence à évoluer avec un agrandissement en un seul coup
    En bas, elle est plus impactée par la modif en 2 temps

    Nom : évolution_transp.jpg
Affichages : 157
Taille : 136,3 Ko

    C'est désagréable, je trouve...

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Bonsoir,

    mauvaise nouvelle...

    La manip que j'ai indiquée ce matin, le resize en deux temps, je ne sais pas si elle améliore, par contre je sais qu'elle dégrade.

    Donc réflexion faite après examen des fichiers, je ne la conseille pas.

    Démonstration (et comm' d'hab', je suis tombé dessus par hasard) et récit de la découverte :

    je regardais tranquillement le rendu du viewer que je suis en train d'envisager de construire et pour ça il me fallait des fichiers à examiner, le dialogue de choix de fichiers me proposant des fichiers récemment ouverts, j'ai choisi, complètement au pif parmi ceux offerts, le Lanczos en 2 passes.

    Bien m'en a pris, car en regardant l'image j'ai découvert des taches noires dans le ciel pur de fin de journée en été, en haut à gauche.
    Alors j'ai lancé d'autres instances du viewer et vous allez pouvoir admirer, de gauche à droite,
    le lanczos 2 passes, donc, puis
    le lanczos 1 passe (sans taches)
    le bicubic 2 passes,
    le bicubic 1 passe (sans taches),
    le linéaire 2 passes (sans taches) et on termine avec
    le linéaire 1 passe (sans taches).
    Nom : 6fichiers+loupe.jpg
Affichages : 162
Taille : 29,9 Ko

    Ensuite à droite ma loupe, qui suit le pointeur de la souris que vous voyez sous la tache du milieu car, oui, il y en a 3 !

    Ci-dessous les détails des 3 premières bandes, après il n'y a plus de tache (et il n'y en a pas non plus dans le Lanczos 1 passe (bandeau central) :
    Nom : zoomx4sur_lanczos.png
Affichages : 154
Taille : 6,8 Ko
    Petite tache en haut, grosse tache au milieu et tache moyenne en bas. D'où sortent-elles ?

    Rien de plus à dire, si ce n'est qu'on trouve donc parfois tout et n'importe quoi sur le net, plus des imbéciles (comme moi) qui colportent et propagent ces infos bidon.
    Sauf que moi, j'apporte des précisions suite aux observations.
    Le drame, c'est que si je n'avais pas vu ces défauts (si j'avais choisi une autre image, par ex.), je me serais lancé dans le plan "je resize en 2 fois", alors qu'in fine c'est pire !

    Peut-être que l'info trouvée sur le site que j'ai donné ce matin date de Mathusalem ?

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 998
    Points : 15 482
    Points
    15 482
    Par défaut
    Citation Envoyé par Jipété Voir le message
    Bonsoir,

    mauvaise nouvelle...
    Bonne nouvelle : ce problème de taches est lié à mon Gimp (et peut-être sa version : 2.8.2) car j'ai fait un essai avec l'unité de resampling d'A. Melander dont j'ai déjà parlé, en deux passes bien sûr (et testé par une pause au milieu pour confirmer que l'image intermédiaire avait bien perdu son ratio), résultat : pas de taches !

    Et même, une qualité esthétique de l'agrandissement nettement supérieure, hé oui...
    Comparez le rendu des arbres, au-dessus des bonbons ou leur reflet dans l'eau à droite, ainsi que le texte :

    Nom : compar_lanczos.gif
Affichages : 178
Taille : 242,3 Ko

    Mais ne tenez pas compte de la perte de beauté (particulièrement dans le ciel), liée à la compression gif.

    Comme quoi, hein, même des outils qu'on imagine redoutables, peuvent faire des blagues...

Discussions similaires

  1. Réponses: 4
    Dernier message: 03/01/2006, 14h44
  2. IIS + Apache + mysql...pour ceux qui ont déjà installé
    Par ludophil dans le forum Autres Logiciels
    Réponses: 1
    Dernier message: 15/10/2005, 03h21

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