Discussion :

[Jipété]

Salut,

Bref j'ai vu que les auteurs XBRV4 avec fait un conversion du XBR avec facteur de 2 originel. A voir je pense

Tu l'as vu où ?

Bon, moi j'en suis là, j'ai bien souffert !
D'abord il faut impérativement travailler sur des bitmap destination en pf24bit, sinon bonjour les traits verticaux.
Ensuite j'avais noté que les changements de rendu de tailles ne s'opéraient qu'aux alentours de valeurcurseur + .05, lié à des Trunc planqués dans une sous-routine d'une sous-procédure, bref, en multipliant par 10 avant l'appel puis en réduisant par 10 l'image traitée, ça devient tout bon, genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
      if NotRound then begin // valeur du curseur avec décimale
        aBmp := (StretchXBR(imgSrc.Picture.Bitmap, scale * 10));
        pnl4Dst.Width  := aBmp.Width  div 10;
        pnl4Dst.Height := aBmp.Height div 10;
        Canvas.StretchDraw(rect(0,0,pnl4Dst.Width,pnl4Dst.Height),aBmp);
      end else begin
        aBmp := (StretchXBR(imgSrc.Picture.Bitmap, scale));
        pnl4Dst.Width  := aBmp.Width ;
        pnl4Dst.Height := aBmp.Height;
        Assign(aBmp);
      end;

Le problème c'est le temps dément que ça prend
4 secondes pour passer de 128x64 à 538x156, je vous laisse imaginer le temps si traitement identique (x 4,2) d'une photo de 4 Mo, 11 minutes à la louche si je ne me suis pas trompé.
Ça risque de limiter l'utilisation, ça...

Regardez attentivement le temps de traitement dans la barre de titre de la fenêtre, à comparer avec le rapport d'agrandissement (label "Step") :



Il y a un test que je n'ai pas bien compris, dans leur code : si le facteur d'échelle est inférieur à 8 ça n'apporte rien, qu'ils disent, alors je l'ai zappé (ainsi que d'autres trucs, en double, et des machins rapatriés dans le fichier de la fiche plutôt que le module, c'est plus logique et plus clair.
Vais peut-être rajouter une option pour n'avoir que de valeurs entières -- ou alors j'ai foiré quelque chose : je viens de vérifier avec la version Windows/Delphi, qui fonctionne avec des valeurs décimales du curseur, sans prendre les temps déments que j'ai vécu.
Bon, à chaque jour suffit sa peine, c'est suffisamment touffu et compliqué comme ça.

[Jipété]

Bonjour,


je suis au désespoir, au 36^e dessous, au fond du gouffre, et je ne vois pas d'issue...

Comme j'estimais que les temps déments d'hier n'étaient pas envisageables, surtout qu'ils n'affectent pas le projet Delphi, j'ai décidé de repartir de la base (concernant le module, car je suis satisfait de ma petite ihm, rapide pour les tests), pour voir ce que ça donne, et force est de reconnaître que ce n'est pas brillant...
Je ne vous inflige pas tout, juste le passage de 10 à 8 :



et face à ça, les bras m'en tombent.

il faut savoir lâcher l'affaire : si j'ai besoin des possibilités de cet outil, je l'utiliserai sous XP, suite à compilation impeccable sous Delphi7.

Et voilà.

[Jipété]

il faut savoir lâcher l'affaire : si j'ai besoin des possibilités de cet outil, je l'utiliserai sous XP, suite à compilation impeccable sous Delphi7.

Grâce au redoutable composant de Jérôme et à son infinie patience face à mes questions parfois lamentables, ben... voilà :



Bon, ça c'est juste la maquette d'étude et de "portage" de D7 vers Laz, le reste (retomber dans les marques de l'ihm d'origine) sera une simple formalité.

Jérôme, comment te remercier ?

[Jipété]

Bonjour,

J'ai fait une catastrophe...

Je ne sais absolument pas ce que j'ai touché hier soir après la génération du gif, toujours est-il que ce matin il m'est impossible de retrouver l'aspect lisse des agrandissements xBR, tout ce que j'ai c'est du moche.
Et je suis sûr et certain de ne pas avoir touché les unités xBR.

Les seules choses modifiées après le gif, c'est de la cosmétique, genre passer, dans uFastBitmap, de ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function TColor32.ToFPColor: TFPColor;
begin
  Result.Red := Self.Red shl 8 + Self.Red;
  Result.Green := Self.Green shl 8 + Self.Green;
  Result.Blue := Self.Blue shl 8 + Self.Blue;
  Result.Alpha := Self.Alpha shl 8 + Self.Alpha;
end;

à ça, que je trouve plus lisible, avec de beaux alignements :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
function TColor32.ToFPColor: TFPColor;
begin
  Result.Red   := Self.Red   shl 8 + Self.Red;
  Result.Green := Self.Green shl 8 + Self.Green;
  Result.Blue  := Self.Blue  shl 8 + Self.Blue;
  Result.Alpha := Self.Alpha shl 8 + Self.Alpha;
end;

Pas de quoi fouetter un chat, hein !

En désespoir de cause je suis reparti des unités de ta dernière démo dans l'autre discussion, mais ça ne change rien.


En haut le gif d'hier, en bas le rendu de ce matin, où l'on notera que les points en haut à droite ont disparu dessous.


On dirait que le problème se situe par là :

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
    with BmpViewerDest do
    begin
      if not RempliD then
      begin
        FastBitmap.ImportFromBitmap
          ( StretchXBR(BmpViewerOrig.FastBitmap.GetBitmap, scale) );
        RempliD := True;
      end;
      // setup des dimensions de la cible
      Width  := W; Height := H;
      Update;
      (FastBitmap.GetBitmap).SaveToFile(chemin + 'xbrmode.bmp'); // le fichier montre
      // que la mise à jour des tailles ne se fait pas, et
      // se fait si les lignes rempliD sont commentées
    end;
  // si les 2 lignes avec RempliD sont commentées, xBR est soft
  // mais rectangle bad -- si décommentées, rect OK mais rendu pas joli

Une démo du rectangle bad ? Y a qu'à demander :


C'est terrible, des trucs pareils.

Un dernier mot : si je passe en mode not_xbr (le bout de code ci-dessus est le mode xbr) alors je bascule avec StretchBlt et je n'ai pas encore compris pourquoi le retour en mode xbr ne s'effectue graphiquement pas, si les lignes RempliD sont actives.

[Jipété]

Yop !

2 jours plus tard...

j'ai réussi à refaire tomber en marche cette usine à gaz (et c'est pas comme ça que j'avais fait la première fois).

Pour faire court, je vous livre le code de la fonction StretchXBR, avec les commentaires (les miens sont taggés "jpt") pour bien comprendre :

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
  ScaleFactor := abs(ScaleFactor);
  if ScaleFactor <= 1.0 then begin // Si ScaleFactor <= 1.0 XBR n'apporte rien donc simple réduction de taille rapide avec StretchBlt
    Result := tBitMap.Create;
//    BmpS.PixelFormat := pf32bit; // jpt : voir commentaires dans initialisations
    Result.Assign(BmpS);
    iKech := round(ScaleFactor);
    goto Achever;
  end else // sinon utilisation du XBR :
    if ScaleFactor >= 8.0 then sKech := Scalefactor
    else sKech := 8.0; // Si ScaleFactor < 8.0 on procède à un XBR avec 8 et qui sera suivi d'un ajustement de taille rapide avec StretchBlt
 
  iKech := round(sKech);
  Initialisations;
 
  for ys := 0 to HS - 1 do begin
// jpt [comment. fonctionnel pour le forum] ici rien n'a été touché, je l'enlève pour alléger, à reprendre de l'original
    end; // for xs
//jpt    if ToucheCla(VK_ESCAPE) then EXIT; // ne compile pas : c'est quel uses qui manque ?
    if Assigned(ProgressCallBack) then ProgressCallBack;
  end; // for ys
 
  Achever:
  //jpt if iKech <> ScaleFactor then -- si présent, ne fonctionne plus avec les val entières > 8
  begin // Ajustement de taille si ScaleFactor n'est pas une valeur entière ou s'il est inférieur à 8
    //jpt WR := round(ScaleFactor * bmpS.Width); HR := round(ScaleFactor * bmpS.Height); // + lisible dessous
    WR := round(WS * ScaleFactor); HR := round(HS * ScaleFactor);
 
    tmp:=TBitmap.Create; // jpt, nouveau
    //tmp.PixelFormat := pf32bit;
    tmp.PixelFormat := pf24bit; // +1 !
    tmp.Width := WR; // 2 lignes nécessaires sinon fichier vide
    tmp.Height:= HR;
 
    //jpt inconnu sous Linux GetBrushOrgEx(Result.Canvas.Handle, pt);
    //jpt SetStretchBltMode(Result.Canvas.Handle, HalfTone);
    SetStretchBltMode(tmp.Canvas.Handle, HalfTone);
    //jpt inconnu sous Linux SetBrushOrgEx(Result.Canvas.Handle, pt.x, pt.y, @pt);
 
    //jpt StretchBlt(Result.Canvas.Handle, 0, 0, WR, HR,
    StretchBlt(tmp.Canvas.Handle, 0, 0, WR, HR,
        Result.Canvas.Handle, 0, 0, Result.Width, Result.Height, SRCCOPY);
 
    //jpt    with Result do begin Width := WR; height := HR; end; // commenté car inutile
    Result.Assign(tmp);
    tmp.Free;
  end;
  Result.Canvas.Changed; // jpt +1!
  SetLength(pixS, 0, 0); SetLength(pixR, 0, 0);
end; // StretchXBR

Le truc qui tue ! : tous les bitmaps sont en pf32, et pourtant,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    //tmp.PixelFormat := pf32bit;
    tmp.PixelFormat := pf24bit; // +1 !

Go figure...

J'ai à peine changé le nom de deux variables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  skech: Single;  // coefficient d'échelle jpt : renommé Kech en sKech (harmonie avec iKech)
  smkech: Single; // moitié du coefficient d'échelle--jpt: mikech à l'origine, idiot

et en ai rajouté une :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  tmp: TBitmap; // jpt

Les modifs dans initialisations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    // BitMap-Source
//    BmpS.PixelFormat := pf32bit;
// jpt : je commente car sinon, ça détruit l'original d'où génération de fichier vide !
// et de toute façon c'est déjà en pf32 si bzBmpViewer

un peu + bas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//        PRGBQuad(pixR[y, x])^.rgbReserved := 0; // ??? jpt
        PRGBQuad(pixR[y, x])^.rgbReserved := 255;

et toute la partie // Affichage des coeffs : est commentée, je reviendrai dessus + tard.

J'arrive à ça, c'est pas mal du tout (légèrement réduit),



mais je suis à 98 % de réussite, car il reste deux soucis :
1-) pas d'image si rapport < 1.0, et
2-)
- avec 128x64, agrandissement jusqu'à 20 fois (soit 2560x1280) sans pb, en pf24 comme pf32 -- pas allé plus loin.
- avec 127x63, agrandissement jusqu'à 8.50, et à 8.51, bim (pf24 comme pf32) ! (là, c'est la fenêtre du prog qui est réduite) :



Bon, ça ira comme ça pour aujourd'hui...

[Jipété]

mais je suis à 98 % de réussite, car il reste deux soucis :
1-) pas d'image si rapport < 1.0, et
2-)
- avec 128x64, agrandissement jusqu'à 20 fois (soit 2560x1280) sans pb, en pf24 comme pf32 -- pas allé plus loin.
- avec 127x63, agrandissement jusqu'à 8.50, et à 8.51, bim (pf24 comme pf32) ! (là, c'est la fenêtre du prog qui est réduite) :

99 %, le point "1" est réglé comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
    //jpt WR := round(ScaleFactor * bmpS.Width); HR := round(ScaleFactor * bmpS.Height);
    // + lisible dessous
//    WR := round(WS * ScaleFactor); HR := round(HS * ScaleFactor);
// peut-être utile si ScaleFactor <= 1
    WR := round(bmpS.Width * ScaleFactor); HR := round(bmpS.Height * ScaleFactor);

car WS et HS sont calculés dans Initialisations, qui n'est pas appelé si ScaleFactor <= 1.
Vous pouvez donc virer les lignes 1 à 4.

[Jipété]

Bonjour,

avec 127x63, agrandissement jusqu'à 8.50, et à 8.51, bim (pf24 comme pf32) ! (là, c'est la fenêtre du prog qui est réduite) :

Aujourd'hui, j'ai jeté un œil au programme D7 ; lui, il part en vrille à partir de 8,20 de rapport d'agrandissement (ici 8,40, on voit qu'il manque le bord inférieur et le côté droit de l'image [copie d'écran réduite de moitié]), et le défaut est reproductible en augmentant le rapport d'agrandissement.
En incrustation une vue à 200 % sous Linux (fond bleu clair de la scrollbox) : comparez les coins en bas à droite.

>>> À condition d'utiliser un fichier à largeur exotique, ici 127 <<<.

Donc en gros et pour faire court et simple, ce programme n'a pas été intensivement testé.
Je ne jette pas la pierre aux dév's, quand on regarde le code on se dit qu'ils ont dû souffrir, mais le fait est là.

Et je ne vois absolument pas ce qui pourrait induire ce défaut de scanline sous Linux ou de géométrie sous Delphi à partir d'un certain rapport d'agrandissement.

Un dernier mot : sous Delphi c'est bien au niveau du rendu des pixels que ça coince car si je réduis la fenêtre du prog, je vois apparaître les scrollbars de déplacement H et V en bas et à droite dans les zones blanches, la preuve, c'est ce coup de loupe sur le coin inférieur droit de la copie d'écran, où j'ai forcé le contraste pour bien faire apparaître la zone blanche de l'image non remplie, puis la zone vide du prog en gris clair et ses lignes de bordures :


Des idées, les gens ?

[BeanzMaster]

Salut

Pour la route petit cadeau Stretch XBR 100% avec TFASTBITMAP + Stretch Bicubic en prime



Comme on peut le voir, il y'a quand même des artefacts. Ce redimensionnement XBR, n'est pas assez précis à mon gout mais c'est déja pas mal

Le code de test : FastBitmapStretchXBR.zip

A+

[Jipété]

Salut,

et grand bravo pour le boulot accompli.

Comme on peut le voir, il y a quand même des artefacts. Ce redimensionnement XBR, n'est pas assez précis à mon goût mais c'est déjà pas mal

J'ai bien vu le défaut (en haut toi, en bas moi) :


je vais regarder ça, toi, de ton côté il te faudrait étudier les timings et les boucles parce qu'en l'espèce, ton projet est juste inutilisable dès qu'on dépasse les tailles "timbre-poste" des fichiers source.
Déjà, regarde bien les barres de titre de l'image précédente, ensuite voilà un exemple avec un fichier de 250x250, à qui il faut plus de 2 secondes pour arriver à 750x750 :


Je m'en suis rendu compte hier soir à pas d'heure, dans le sens de la "redescente" où on dirait que les timings sont encore plus dramatiques (je suis à 1,792 pour redescendre de x3 à x2).
Et je précise que les copies d'écran ont été réalisées hors EDI.

Le code de la mesure du temps (directement du projet D7) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
var
  GTC: DWord; 
begin
  GTC := GetTickCount;
  //... action à mesurer
  Caption := 'StretchXBR, temps : ' + intToStr(GetTickCount - GTC) + ' ms';
end;

Allez, cent fois sur le métier remettons-nous à l'ouvrage !

[Jipété]

Question timing, dans cette Function TFastBitmap.BuildBitmap: Graphics.TBitmap; vers la ligne 850, j'ai vu ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Var
  IntfBmp : TLazIntfImage;
Begin
  ...
  SrcPix := Self.GetSurfaceBuffer;
  For Y:=0 to H-1 do
  begin
    For X:=0 to W-1 do
    begin
      IntfBmp.Colors[x, y]:=SrcPix^.ToFPColor;
      inc(SrcPix);
    end;
  end;

qui m'a fait penser au classique bmp.Canvas.Pixels[x, y] bien connu pour sa lenteur et donc remplacé par du scanline un peu partout.

Alors j'ai fait l'essai suivant :

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
var
  PixelCount : Integer; // jpt
  ByteIdx: integer; // jpt
Begin
  ...
  SrcPix := Self.GetSurfaceBuffer;
{  For Y:=0 to H-1 do
  begin
    For X:=0 to W-1 do
    begin
      IntfBmp.Colors[x, y]:=SrcPix^.ToFPColor;
      inc(SrcPix);
    end;
  end;      }
  PixelCount := (FWidth * FHeight);
  ByteIdx := 0;
  while pixelCount > 0 do
  begin
    IntfBmp.PixelData[ByteIdx+0] := SrcPix^.getColorComponent(ByteIdx+0);
    IntfBmp.PixelData[ByteIdx+1] := SrcPix^.getColorComponent(ByteIdx+1);
    IntfBmp.PixelData[ByteIdx+2] := SrcPix^.getColorComponent(ByteIdx+2);
    IntfBmp.PixelData[ByteIdx+3] := SrcPix^.getColorComponent(ByteIdx+3);
    Inc(ByteIdx, 4);
    Dec(pixelCount);
  end;

puis j'ai poussé plus loin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
  SrcPix := Self.GetSurfaceBuffer;
{  For Y:=0 to H-1 do
  begin
    For X:=0 to W-1 do
    begin
      IntfBmp.Colors[x, y]:=SrcPix^.ToFPColor;
      inc(SrcPix);
    end;
  end;}
  SetupColors(IntfBmp, SrcPix, FWidth * FHeight);

avec

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
procedure SetupColors(const lii: TLazIntfImage; var sp: PColor32; pc: integer); inline;
var
  bx: integer;
begin
  bx := 0;
  while pc > 0 do
  begin
    lii.PixelData[bx+0] := sp^.getColorComponent(bx+0);
    lii.PixelData[bx+1] := sp^.getColorComponent(bx+1);
    lii.PixelData[bx+2] := sp^.getColorComponent(bx+2);
    lii.PixelData[bx+3] := sp^.getColorComponent(bx+3);
    Inc(bx, 4);
    Dec(pc);
  end;
end;

mais je ne gagne rien, malgré le inline
Pourquoi ?
Avec les optimisations rapides et les liens intelligents (qu'est-ce que ça veut dire ?), hors EDI, le 250x250 a besoin de 1,5 seconde pour monter à 750x750, c'est énorme et impensable d'aller plus haut. Je ne te jette pas la pierre, le code d'origine a besoin de 1,7 pour le même taf (zéro optimisation), mais ça va être ennuyeux de bosser avec cet outil.


Autre chose : dans uBmpViewer, ligne 2246 il y a encore un vieux machin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
// jpt                          IsOpaque := IsOpaque and (DstColor.alpha = 255);
                           IsOpaque := IsOpaque and (DstLine^.alpha = 255);

Correct ou pas correct ? D'autant plus que 2281 est à jour.

Mais pas les identifiants de version,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
(*==============================================================================
 DESCRIPTION   : Composant visuel pour l'affichage d'une image au format
                 BMP (Widows / OSx Bitmap)
 DATE          : 19/02/2019
 MISE A JOUR   : 21/02/2018 12:00:00
 VERSION       : 1.0
 AUTEUR        : J.Delauney (BeanzMaster)
 CONTRIBUTEURS :
 LICENCE       : MPL
================================================================================
*)

Et pas mieux pour uFastBitmap :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
(*==============================================================================
 DESCRIPTION   : Classe de manipulation basique de bitmap en 32 bit.
                 Basic Class for manipulating 32 bit Bitmap
 DATE          : 17/06/2018
 MISE A JOUR   : 21/02/2019
 VERSION       : 1.0
 AUTEUR        : J.Delauney (BeanzMaster)
 LICENCE       : MPL
================================================================================
*)

alors qu'il a grave évolué !

À ce propos, la fonction ClampByte devrait être remontée tout en haut ligne 397 juste après sa copine Clamp, non ?
Juste cosmétique, mais c'est du bon sens, et ça permettra de mieux les comparer.


Quant au défaut de rendu, je ne vois pas trop où ça coince...
S'il faut vérifier par comparaison ligne à ligne la source D7 et ta dernière version, c'est un 13^e travail d'Hercule, ça,

Dans l'unit3, je te l'ai déjà signalé, tu l'as aussitôt zappé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
    1 :  // StretchBlt
    begin
      TmpBmp := TBitmap.Create;
      TmpBmp.PixelFormat := pf32bit; // ICI ! Juste après le create.
      TmpBmp.Width  := W;
      TmpBmp.Height := H;
// jpt      TmpBmp.PixelFormat := pf32bit;

That's all, folks,

[Jipété]

Porter ce projet vers Lazarus était une très mauvaise idée...

J'ai eu une intuition dramatique : j'ai pris un fichier 250x250 en pf24 et l'ai fait ouvrir par le prog Delphi sous XP.
Avec un rapport de 10 (pas 3, 10 !), ça a juste mis 0,2 sec.

Je crois qu'on peut jeter tout ce qui s'appuie sur Lazarus...

[BeanzMaster]

Salut

JP pour ton post d'avant en ce moment pas trop le temps d'approfondir ces petites choses en interne . Je me concentre sur le problème principal. Juste pour le temps c'est que dans la version FastBitmap j'ai viré les tampons "TScanYX" d'ou la perte de performance. Mais ce n'est pas bien grave je les ai remis

Pourrais tu fournir le code de ta conversion Delphi-->Lazarus du projet XBR stp ?

Car voila :

Le projet compilé avec Delphi CE 10.3. : Nickel



Ma conversion :



La version TFastBitmap légérement modifié par rapport à la précédente :



Je n'arrive pas à trouver ou est le problème de ces artefacts (les carrés noir en sus) . Notes j'ai vérifié les coeffs avec la version Delphi se sont les mêmes


Merci

Bonne nuit

[Jipété]

Yop !

Je n'arrive pas à trouver où est le problème de ces artefacts (les carrés noirs en sus).

Ne perds pas ton temps !
Après tout, si une version Windows fonctionne bien (et est facilement retouchable avec Delphi, je ne suis pas chauvin ni raciste ni xénophobe ni rien de tout ça, donc, prendre le bon outil pour faire le bon boulot et roule !), pourquoi se prendre la tête à essayer de réinventer la roue, surtout si elle sort carrée au bout du compte ?

Pourrais-tu fournir le code de ta conversion Delphi-->Lazarus du projet XBR stp ?

Dans l'outil de conversion,
- je n'ai pas coché "Support de Delphi", résultat rien de changé dans les unités, on trouve partout {$MODE Delphi},

- il a fallu que je clique deux fois sur "Supprimer les commentaires" (qui veut dire, en bon français, "Mettre en commentaire" ! Bravo la traduc ! Faudrait vérifier avec une v2 et faire remonter au besoin dans la discussion qui va bien -- et pourquoi 3 options dans la liste mais 4 boutons ?
) :

une fois pour uDemoV4.pas, uses axCtrls
et une autre fois pour uGifImage.pas, uses Consts, ligne 1399


J'ai enregistré, et par curiosité j'ai ouvert le projet converti.
C'est une catastrophe.
La fiche est intégralement vide, mis à part ces 3 choses :



Je ne me souviens pas de comment j'avais fait pour y arriver il y a deux mois (j'oublie les mauvais plans), juste le souvenir que j'avais miséré avec le TNotebook, je crois bien que j'étais parti du .dfm renommé en .lfm et à coups d'ouverture - message d'erreur - fermeture et édition pour correction, j'y suis finalement arrivé.

Bon courage (je ne sais plus pourquoi, mais j'ai également viré dans mon projet de test l'unité pour les Gifs).
conversion4bz.zip

Ah, j'ai apporté hier une petite info complémentaire là, chez les voisins, puisque GG y a un peu (à peine !) causé de son bébé.

[Jipété]

Une info complémentaire qui montre bien que le projet d'origine a été mal testé (ou que ce que j'ai tenté n'est pas son but final) mais hier, avec la version D7 restée avec le zoom par défaut (à 10, donc), je n'ai pas pu ouvrir un fichier jpeg de 560 x 700 environ : me suis fait insulter avec un "pas assez de ressources disponibles" ou similaire très désagréable.

Ce matin j'ai fait autrement : j'ai ouvert mon fichier avec x2, et l'ai "monté" jusqu'à x8 (pas essayé plus haut), ai voulu l'enregistrer et bim !

---------------------------
Stretchxbr_v4
---------------------------
Erreur d'écriture dans le flux.
---------------------------
OK
---------------------------

Bon ok, ça donnait un fichier d'environ 100 Mo, mais est-ce que Gimp se/me prend la tête avec ça ?

Idem en le "redescendant" à 7, ok à 6, pas testé les valeurs intermédiaires pour savoir où ça coince.

Ensuite, ce fichier x6 je l'ai ouvert avec Gimp parce que les vaguelettes autour de et dans l'œil, franchement ça le fait pas.
J'ai donc d'abord fait un agrandissement "linéaire" de l'original avec Gimp (en bas à droite) pour comparer, puis dans une autre fenêtre j'ai ouvert et flouté la sortie xBR (en haut), fenêtre que j'ai dupliquée pour renforcer la netteté (en bas à gauche).



Après toute cette cuisine, c'est pas trop mal on va dire.

Et du coup vous faites connaissance avec ma grand-mère jeune,
Ce cliché doit bien avoir une centaine d'années...

Attention avec cet outil : l'image originale a une définition de 150 dpi, xBR l'a faite sauter, et on se retrouve à 72,

Une autre comparaison, pour terminer :

[BeanzMaster]

Dans l'outil de conversion,
- je n'ai pas coché "Support de Delphi", résultat rien de changé dans les unités, on trouve partout {$MODE Delphi},

- il a fallu que je clique deux fois sur "Supprimer les commentaires" (qui veut dire, en bon français, "Mettre en commentaire" ! Bravo la traduc ! Faudrait vérifier avec une v2 et faire remonter au besoin dans la discussion qui va bien -- et pourquoi 3 options dans la liste mais 4 boutons ?
) :

une fois pour uDemoV4.pas, uses axCtrls
et une autre fois pour uGifImage.pas, uses Consts, ligne 1399

Dommage que tu n'ai pas mis le projet final convertit par tes soins cela serait plus simple pour moi pour comparer, vu que je ne dispose que de très peu de temps libre en ce moment

Je vais essayé de fouiller un peu plus d'ici demain, dès que j'en aurais finis avec mes papiers

A+

[Jipété]

Dommage que tu n'ai pas mis le projet final converti par tes soins cela serait plus simple pour moi pour comparer, vu que je ne dispose que de très peu de temps libre en ce moment

Fallait tout bien lire :

Bon courage (je ne sais plus pourquoi, mais j'ai également viré dans mon projet de test l'unité pour les Gifs).
conversion4bz.zip

Peut-être que le passage entre parenthèses prête à confusion ? J'ai pourtant bien précisé dans mon projet, alors que le .zip t'est destiné.

[BeanzMaster]

Fallait tout bien lire :

Peut-être que le passage entre parenthèses prête à confusion ? J'ai pourtant bien précisé dans mon projet, alors que le .zip t'est destiné.

Je l'ai bien téléchargé mais faut tout reprendre lfm (a cause du notebook) + le reste bref....Même en magouillant un peu ca ne compile pas

uStretchXBRV4.pas(94,9) Warning: Conversion between ordinals and pointers is not portable
uStretchXBRV4.pas(94,9) Error: Typecast has different size (4 -> 8) in assignment

Bref si ca compile chez toi et pas chez moi c'est surement du à 32<>64 bits

A+

[Jipété]

Je l'ai bien téléchargé mais faut tout reprendre lfm (a cause du notebook) + le reste bref....Même en magouillant un peu ca ne compile pas

Essaye avec mon unité ; au final, j'y suis arrivé (et, oui, le Notebook m'a fait grave souffrir) -- cherche les tags "jpt" pour voir ce que j'ai bidouillé (pas grand chose, et surtout de la compatibilité avec Linux).
uDemoV4fiche.zip

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

uStretchXBRV4.pas(94,9) Error: Typecast has different size (4 -> 8) in assignment

Bref si ca compile chez toi et pas chez moi c'est surement du à 32<>64 bits

T'aurais dû aussi mettre la ligne de code, pour être sûr qu'on voit la même.
Moi j'ai ça en ligne 94 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PRGBQuad(pixR[y, x])^.rgbReserved := 0;

Ce qui est bizarre, c'est que la ligne précédente a pratiquement la même écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PRGBQuad(pixR[y, x])^ := ColorVersClQuad(clWhite);

et elle n'a pas d'erreur ?

Il me semble pourtant que tu avais écrit il y a qq jours que tu avais réussi à obtenir une unité qui compilait.
Encore un mystère...