[Windows - Linux] Porter le projet Delphi StretchXBR vers Lazarus

Version imprimable

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

01/03/2019, 12h56
Jipété

2 pièce(s) jointe(s)

[Windows - Linux] Porter le projet Delphi StretchXBR vers Lazarus
Bonjour,

je préfère ouvrir une nouvelle discussion pour ce sujet, qui risque d'être passablement tendu et compliqué.

Car j'ai jeté un coup d'œil rapide à un des modules (uManipBMPV4), et celui-ci est blindé d'utilisations de RGBQuad et autres RGBTriple avec les conversions qui vont bien, mais aussi de conversions pf24 (Windows oblige) vers pf32 pour bosser, je crains ici une grosse consommation d'aspirine et autres anti-dépresseurs, :ptdr:

Pour commencer je redonne la source, et les modifs que j'ai apportées à la fiche principale et à l'unité de travail également ~~(nouveau zip par rapport à celui d'hier)~~ EDIT : lire dessous

Mais ATTENTION ! Je constate avec stupéfaction et tristesse, si si !, que toutes les corrections que j'ai apportées hier à la fiche (.lfm) sont complètement en vrac et ignorées ce matin :
Pourquoi ?
Une idée pour remettre tout ça d'équerre sans être obligé de tout refaire à la mano ?
EDIT : j'ai refait, à coups de rechercher / remplacer tout, ça devrait être bon : Pièce jointe 454143

Ouvrez les fichiers et cherchez "jpt".

Ensuite, je crois qu'il faut penser dès à présent à l'utilisation de machins conditionnels genre
Code:

1 2 3 4 5 {$IFDEF LINUX} // actions pour le pingouin {$ELSE} // actions pour la fenêtre {$ENDIF}
Il faut arriver jusque là :
Pièce jointe 454145
01/03/2019, 15h09
BeanzMaster

:calim2::weird: Re-Hello ca serait vraiment sympa si tu pourrais nous mettre le projet complet. Vraiment pas le temps et envie de me faire ***** à convertir les units de Delphi, créer un projet insérer ta Form supprimer l'ancienne bref. Un petit Zip All-in-one ne serait pas de refus et désagréable :whistle::zoubi:
01/03/2019, 15h20
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par BeanzMaster

:calim2::weird: Re-Hello ca serait vraiment sympa si tu pourrais nous mettre le projet complet. Vraiment pas le temps et envie de me faire ***** à convertir les units de Delphi, créer un projet insérer ta Form supprimer l'ancienne bref. Un petit Zip All-in-one ne serait pas de refus et désagréable :whistle::zoubi:

Tes désirs sont des ordres :hola: : Pièce jointe 454181

Mais souviens-toi que j'ai déjà commencé à mettre en commentaires des choses qui empêchent la compil Linux.
Bref, cherche "jpt", tu verras bien.

J'ai bien compris ton autre message et donc je suppose que celui-ci ne va pas beaucoup avancer, paniproblem', maintenant, si tu détectes un truc énorme dans une fonction ou procédure ou que sais-je, plutôt que de recréer tout un zip, si tu pouvais poster juste les modifs, histoire de voir facilement ce qui évolue, ça serait ~~bien~~ ~~mieux~~ top !
01/03/2019, 16h30
BeanzMaster

Merci :ccool::plusser:

Je viens de jeter un oeil vite fait, quel cata ! Pour convertir ce projet en utilisant les TBitmap de Lazarus va falloir être super minutieux. Les fonctions utilisent énormément les pointeurs et certains truc sont incompatibles avec Lazarus dans la façon de faire, mais ce n'est pas insurmontable. En plus il y a des échanges RGB<=>RGBA qui ne servent à rien, mise à part alourdir la compréhension de l'algo. Mieux vaut travailler en RGBA directement. Après quelques changement vite fait. Impossible de tester

Citation:

StretchXBR_V4.lpr(18,1) Error: Can't open resource file "H:\BeanzMaster\Documents\Projets\Lazarus\test\XBR\StretchXBR_V4.res" :aie:

J'essayerai de convertir ce XBR via TFastBitmap dès que j'aurais un peu de temps, mais ca risque d'être chaud ce WE, je suis invité Samedi et Dimanche

A+
01/03/2019, 19h28
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par BeanzMaster

Impossible de tester

Code:

StretchXBR_V4.lpr(18,1) Error: Can''t open resource file "StretchXBR_V4.res"

Ça, c'est un mystère : je n'ai pas mis le .res pour ne pas alourdir le zip car normalement une compil doit le recréer, mais des fois oui et des fois non...
D'autant plus qu'on trouve souvent des zip sans .res et ça fonctionne. :koi:
Bref... : Pièce jointe 454240
Tu enlèveras ".txt".

Citation:

Envoyé par BeanzMaster

J'essayerai de convertir ce XBR via TFastBitmap dès que j'aurais un peu de temps, mais ca risque d'être chaud ce WE, je suis invité Samedi et Dimanche

On n'est pas pressés, ne te prends pas la tête, je pense que je vais avoir suffisamment à faire avec le projet "bicubics" et le défaut de géométrie/couleurs, si tu as autre chose à faire de ta vie, personne ne t'en voudra.
01/03/2019, 22h23
der§en

Je vais creuser ton code mais pour un besoin perso un peu détourné de son usage premier :mouarf:
02/03/2019, 02h09
Roland Chastain

1 pièce(s) jointe(s)

Bonjour Jipété (et les autres) !

Très intéressant ton programme. Si tu arrives à le faire fonctionner (ce dont je ne doute pas), il pourra me servir à faire quelque chose que j'avais en tête (agrandir des pièces de jeu d'échecs).

En attendant j'ai cherché si ImageMagick ne faisait pas ce genre de choses et je suis très content de ce que j'ai trouvé, même si ce n'est pas ce à quoi je pensais au départ. Ce à quoi je pensais, c'est ce que ton programme semble faire (remplacer les petits pixels par de gros pixels, en quelque sorte).

Pour mémoire, la ligne de commande IM.

Code:

C:\Roland\outils\imagemagick\convert.exe bb.bmp -magnify bb80.bmp

Ci-joint l'image que j'ai utilisée et le résultat. :love:

Apparemment on ne peut pas attacher de fichier BMP. Peut-être qu'il peut y avoir des virus dedans.
02/03/2019, 08h52
Jipété

2 pièce(s) jointe(s)

Bonjour Roland (et les copains),

Citation:

Envoyé par Roland Chastain

Très intéressant ton programme.

Merci de ton intérêt.
Juste une précision, ce n'est pas mon programme, c'est un truc de la bande aux voisins (cirec, gilbert geyer et al), ce qui m'intéresse c'est de le porter sous Laz car pour y trifouiller dedans (au cas où), c'est plus confortable avec l'EDI de Laz (même si je suis en retard de plusieurs versions) qu'avec mon vieux Delphi7 pour lequel il faut que je démarre une machine virtuelle Win2000 un peu à la manivelle (pas compris pourquoi).

Citation:

Envoyé par Roland Chastain

Si tu arrives à le faire fonctionner (ce dont je ne doute pas), il pourra me servir à faire quelque chose que j'avais en tête (agrandir des pièces de jeu d'échecs).

L'ami Jérôme a regardé dedans et il semblerait que ça soit la misère.
Ça va donc prendre du temps...

À l'heure actuelle, l'ayant compilé pour tests il y a un mois, je l'utilise sous XP, et je vais te faire pleurer, ça fonctionne aussi bien que ce que j'avais constaté la première fois.

Démo : j'ai pris ton bb (je pensais à l'autre, dommage :cry:), l'ai ouvert (bouton [pas visible sur la copie d'écran] à droite :koi:), ai réglé le zoom à 200 % (il fonctionne avec les flèches du clavier, heureusement), et clic sur le gros bouton central et zou !

Pièce jointe 454314

Pour comparer j'ai rajouté ton bb80 dans le viewer Linux par-dessus, et on voit bien qu'il n'y a pas photo :P.

Dans l'attente d'un code fonctionnel (j'ai l'autre problème de géométrie sur les bras...), j'ai zippé l'exe et deux fichiers car la sortie du prog générant des .bmp en 32 bits (ce qui risque de ne pas être apprécié de tous les destinataires), j'ai pris ce 32 et l'ai converti en 24 grâce au Gimp sans rien toucher d'autre.
Paquet-cadeau : un exe 32 (qui tourne bien sous XP sp2 32 bits) et 2 .bmp : Pièce jointe 454318

Enjoy, et bon week-end.

PS :

Citation:

Envoyé par Roland Chastain

Apparemment on ne peut pas attacher de fichier BMP. Peut-être qu'il peut y avoir des virus dedans.

On pourrait en dire tout autant des tif, gif, jpg et peut-être png, je n'ai pas étudié leur structure.
Je penche plus pour une histoire de tailles démentes, c'est sûr que ton bb de 5 ko ne devrait pas gêner. Bah...

Citation:

Envoyé par der§en

Je vais creuser ton code mais pour un besoin perso un peu détourné de son usage premier :mouarf:

Tu nous raconteras, tu mets ma curiosité à rude épreuve, :mrgreen:
02/03/2019, 09h42
Roland Chastain

Merci Jipété. :ccool:

Citation:

Envoyé par Jipété

(je pensais à l'autre, dommage :cry:)

Désolé pour la fausse joie. :ptdr:
02/03/2019, 22h28
BeanzMaster
Citation:

Envoyé par Jipété

Ça, c'est un mystère : je n'ai pas mis le .res pour ne pas alourdir le zip car normalement une compil doit le recréer, mais des fois oui et des fois non...
D'autant plus qu'on trouve souvent des zip sans .res et ça fonctionne. :koi:
Bref... : Pièce jointe 454240
Tu enlèveras ".txt".

On n'est pas pressés, ne te prends pas la tête, je pense que je vais avoir suffisamment à faire avec le projet "bicubics" et le défaut de géométrie/couleurs, si tu as autre chose à faire de ta vie, personne ne t'en voudra.

Salut,

j'ai résolu le problème du res sans ton fichier merci quand même. En fait il faut aller dans les options du projet ==> Options du projet ==> Application et cocher "utiliser les ressources manifest". Du moins sous Windows et la hop le fichier Res est recréé.

J'ai donc réussis à compiler le projet. Avec les "Stretchbits" pas de soucis. Par contre avec le XBR je me prend un gros SIGSEGV ici :

Unité uStretchXBR4
Code:

1 2 3 4 procedure SetPixelOut; //paramètres : ixr,iyr: integer; clPixOut: tRGBQuad begin if (ixr >= 0) and (iyr >= 0) and (ixr < WR) and (iyr < HR) then pixR[iyr, ixr]^ := clPixOut; end;
J'ai modifié vite fait les types des pointers, mais je pensez que l'erreur vient de l'utilisation des type déclarés qui sont des "array"
Code:

1 2 type tScanYX = array of array of PRGBAQuad; // Tableau des adresses des pixels
Je pense qu'il y a un soucis avec les SetLength J'avais lu un topic la dessus sur le forum anglais (faudrais que je le retrouve)

Et mon dieu que le code des unités uStretchXBR4 et uManipBMPV4 est crade :weird: pas d'indentation, pas de retour à la ligne, c'est vraiment désagréable à lire, réutilisation de types similaires local au lieu de global, vraiment pas évident de s'y retrouvé.
Même si le code est plus ou moins intéressant, il est anarchique dans la façon d'utilisation des pointers pour les échanges avec les TBitmap et c'est un peu bourrin de mon point de vue.

Sur wiki il y a quelques explications concernant l'algo XBR et ici et des liens vers des sources en C/C++ plutôt intéressant comme le HQx.
Un algo qui me donne envie est Waifu2x la qualité des images redimensionnée est stupéfiante. Site officiel avec convertisseur en ligne ici

A+

[EDIT] Tuto sur l'algo XBR[/EDIT]

1 pièce(s) jointe(s)

Yop !
Citation:
Envoyé par BeanzMaster
J'ai donc réussi à compiler le projet. Avec les "Stretchbits" pas de soucis. Par contre avec le XBR je me prend un gros SIGSEGV ici :

Unité uStretchXBR4
Code:

1 2 3 4 procedure SetPixelOut; //paramètres : ixr,iyr: integer; clPixOut: tRGBQuad begin if (ixr >= 0) and (iyr >= 0) and (ixr < WR) and (iyr < HR) then pixR[iyr, ixr]^ := clPixOut; end;
Windows ou Linux ?

Parce que moi, je n'ai que le Stretchbit sans halftone qui fonctionne correctement, l'autre ne fait rien mais c'est certainement lié au fait que
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 procedure DoStretchBlt(HalfTon: boolean); var pt: TPoint; s: string; begin with FrmDemoMain do begin edMis.text := ''; edMis.Update; GTC := GetTickCount; // 3 instructions incompatibles avec Linux jpt if HalfTon then begin // if GetStretchBltMode(imgResized.Picture.Bitmap.Canvas.Handle) <> HalfTone then // begin GetBrushOrgEx(imgResized.Picture.Bitmap.Canvas.Handle, pt); SetStretchBltMode(imgResized.Picture.Bitmap.Canvas.Handle, HalfTone); // SetBrushOrgEx(imgResized.Picture.Bitmap.Canvas.Handle, pt.x, pt.y, @pt); // end; s := 'StretchBlt & HALFTONE '; end else s := 'StretchBlt SANS HALFTONE ';
.
Et le XBR passe sans AV mais avec un résultat, hummm :

Pièce jointe 454396

Merci pour les liens sur la documentation, ça sera surement très utile :ccool:

Bon, on a du pain sur la planche, mais quand on voit certains rendus, on a vraiment envie de se retrousser les manches, non ? ;)

03/03/2019, 00h18
BeanzMaster

Citation:

Envoyé par Jipété

Yop !

Windows ou Linux ?

Parce que moi, je n'ai que le Stretchbit sans halftone qui fonctionne correctement, l'autre ne fait rien mais c'est certainement lié au fait que [CODE]procedure DoStretchBlt(HalfTon: boolean);

Et le XBR passe sans AV mais avec un résultat, hummm :

Pièce jointe 454396

Merci pour les liens sur la documentation, ça sera surement très utile :ccool:

Bon, on a du pain sur la planche, mais quand on voit certains rendus, on a vraiment envie de se retrousser les manches, non ? ;)

C'est sous Windows.

Pour le strecthbit je pense que c'est une limitation de Lazarus car sous Linux cette fonction est "émulée" alors que sous windows c'est une fonction API.

Faudrait que l'on compare les modifs que l'on a fait chacun sur l'unit "uStrectchXBRv4". pour voir les différences

Sinon pour l'autre unit uManipBMPv4" avec les filtres (luminosité et autres je me prend un sigsegv). Mais bon j'ai fait des modifs un peu "ala one again"

Et c'est clair qu'il y a du boulot. par contre je pense que je vais plus creuser vers les codes en C/C++ il me paraissent plus structurés et simples pour un portage, à la limite un mix entre les deux Delphi/C. A étudier.
03/03/2019, 00h27
Jipété

Citation:

Envoyé par BeanzMaster

Faudrait que l'on compare les modifs que l'on a fait chacun sur l'unit "uStrectchXBRv4". pour voir les différences

Si tu as pris le projet là :

Citation:

Envoyé par Jipété

Tes désirs sont des ordres :hola: : Pièce jointe 454181

voilà :

Citation:

Envoyé par Jipété

Mais souviens-toi que j'ai déjà commencé à mettre en commentaires des choses qui empêchent la compil Linux.
Bref, cherche "jpt", tu verras bien.

Et je n'y ai plus touché, je voudrais avancer la géométrie de l'autre...

PS : ce soir j'ai regardé waiku (450 Mo à télécharger, ouch !), je n'y comprends rien. C'est du lua, je ne connais pas du tout, ça a l'air passablement illisible...
Ne nous dispersons pas !

Au dodo,
:coucou:
03/03/2019, 03h36
BeanzMaster

J'ai bien vu tes modifs dans l'unité uStretchXBRV4

mais comment se fait-il que, par exemple

Code:

Scan0 := BmpS.ScanLine[0];

fonctionne ???? le TBitmap sous lazarus n'as pas de propriété ScanLine[] ???? :calim2:
03/03/2019, 07h59
Jipété

Citation:

Envoyé par BeanzMaster

mais comment se fait-il que, par exemple

Code:

Scan0 := BmpS.ScanLine[0];

fonctionne ???? le TBitmap sous lazarus n'as pas de propriété ScanLine[] ???? :calim2:

Bien sûr que oui !
Sinon ça ne fonctionnerait pas du tout, ça ne compilerait même pas.

Après, pourquoi on dit ça, je n'en sais rien : erreur de traduction qui s'est transformée en légende urbaine ?
03/03/2019, 13h44
BeanzMaster

1 pièce(s) jointe(s)

Citation:

Envoyé par Jipété

Bien sûr que oui !
Sinon ça ne fonctionnerait pas du tout, ça ne compilerait même pas.

Après, pourquoi on dit ça, je n'en sais rien : erreur de traduction qui s'est transformée en légende urbaine ?

Pourquoi on passe toujours par RawImage.getLineStart ??? j'ai zappé un truc !!!

Bref je suis arrivé à quelque chose avec le xbr

Pièce jointe 454458

Le soucis comme toujours c'est que cela fonctionne qu'avec des BITMAP en 32bits (cad RawImage.Description.Depth et Bitcount = 32) sinon c'est mort
De plus, dès qu'il y a transparence idem plein d'artefacts (une horreur) Ici on peux voir des artefacts dans le BMP mais c'est moins pire :scarymov:

Bon je dois partir, je regarderais ça un peu plus tard et donnerai l'unité uStretchXBRv4 modifiée

Bon après midi

A+
07/03/2019, 00h48
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par BeanzMaster

Bon je dois partir, je regarderais ça un peu plus tard et donnerai l'unité uStretchXBRv4 modifiée

En attendant de la voir venir, j'ai pas mal passé le balai dans des vieux codes, on y voit plus clair, je me suis régalé avec les fichiers de Mitchell (2 .pas et 1 .inc, tout ça condensé en une seule unité, cool pour la maintenance), et j'y ai bien note, pour répondre à ça :

Citation:

Envoyé par BeanzMaster

Le soucis comme toujours c'est que cela fonctionne qu'avec des BITMAP en 32bits (cad RawImage.Description.Depth et Bitcount = 32) sinon c'est mort

Citation:

Envoyé par jipété

if biBitCount = 32 then begin // +1 et PAS PixelFormat !

sous-entendu il ne faut pas utiliser RawImage et ses valeurs pourries. :P

Tiens, ce matin j'ai découvert que le convert de ImageMagick (ma vieille version) générait des bitmaps complètement déglingués...

Et sinon, concernant ce projet, j'en suis là, ça n'avance pas vite...
Pièce jointe 455557

Encore une histoire de ph24/pf32, mais quelle horreur ce code...

1 pièce(s) jointe(s)

Citation:

Envoyé par Jipété

Il faut arriver jusque là :
Pièce jointe 454145

Bon, je m'en suis sorti :
- convertir les fichiers d'entrée qui sont en pf24bit en pf32bit (entre autres celui embedded dans la fiche) ;
si ça peut être utile à quelqu'un :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    bmp32:=TBitmap.Create;
    with bmp32 do begin
      PixelFormat := pf32bit;
      Width := BmpS.Width;
      Height:= BmpS.Height;
      p := 0; // position dans le bmp32.rawimage.data 
      for y := 0 to BmpS.Height-1 do
        for x := 0 to (BmpS.Width*3)-1 do begin
          RawImage.Data[p]:=BmpS.RawImage.Data[(y*BmpS.Width*3)+x];// recopier les bytes
          if ((((y*BmpS.Width*3)+x+1) mod 3) = 0) then begin // tous les 3 bytes de la source
            // 1- inverser R et B dans la dest
            b := RawImage.Data[p-2];
            RawImage.Data[p-2] := RawImage.Data[p];
            RawImage.Data[p] := b;
            // 2- ajouter un 4e byte à la destination
            inc(p);
            RawImage.Data[p] := 255;
          end;
          inc(p);
        end;
    end;

- bien penser à rajouter le 4^e byte partout où il est question de TRGBQuad, exemple dans uManipBMPV4 :

Code:

1
2
3
4
5
6
7
8
9
function clQuadMix2(c1, c2: tRGBQuad): tRGBQuad;
begin
  with Result do begin
    rgbRed   := (c1.rgbRed   + c2.rgbRed)   shr 1;
    rgbGreen := (c1.rgbGreen + c2.rgbGreen) shr 1;
    rgbBlue  := (c1.rgbBlue  + c2.rgbBlue)  shr 1;
    rgbReserved := (c1.rgbReserved  + c2.rgbReserved) shr 1; // jpt
  end;
end;

Résultat (réduit au 2/3) :
Pièce jointe 455695

L'image d'en haut est toute moche car redimensionnée en utilisant StretchBlt.
:coucou:

08/03/2019, 00h13
BeanzMaster

2 pièce(s) jointe(s)

:ccool:

Par contre de mon coté avec certaines image l'agrandissement n'est pas précis. ou bien des erreur à cause du "RawImage" (même après conversion vers 32bits)
Cela aurais été bien si on avait acces au code C originel sur lequel les auteurs se sont basé. A la base le XBR agrandit seulement avec des facteurs 2,3,4.
Dans le lien du tuto que j'ai donné plutôt on trouve un lien vers des sources sur github. Ces code sont des scripts HLSL (cgShader) il y a un "super-xbr" avec un facteur de 6, 8 et adaptatif mais l'algo est différent. Il y aussi le XBRz qui prend en charge les facteurs 5 et 6.

Sur Sourceforge j'ai trouvé ce petit outil (On peux également télécharger les sources en C)

Image redimensionnée avec un facteur de 4

Première image avec ScalerTest
Pièce jointe 455913
Image avec StrechXBR4 chez moi
Pièce jointe 455919

On voit bien que le second est moins précis (regardez les jambe du gladiateur par exemple)

[EDIT] Je pense que vous avez remarqué il y a aussi des variations minimes dans les couleurs
L'algo en lui même se débrouille pas trop mal, mais le résultat varie suivant la source
[/EDIT]

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

A+
08/03/2019, 00h38
Jipété
Citation:

Envoyé par BeanzMaster

--snip--

Ouais ouais ouais ouais-ouais...

De mon côté, j'ai décoché :resolu:, vu comment je misère avec certains fichiers qui sont très bien ouverts par les routines Mitchell mais redimensionnés avec les traits verticaux habituels des défauts de scanline...
Je pense entre autres à la série des fichiers FondRVB... tu sais, les carrés 250x250 marron/bleu (le ...32bitsKC), c'est l'enfer.

Ça, plus les redimensionnements laborieux dès que je passe sous un rapport de 800 % (où des commentaires expliquent qu'on bascule en mode StretchBlt), bref, la loose...
Code:

1 2 // Si ScaleFactor < 8.0 on procède à un XBR avec 8 et // qui sera suivi d'un ajustement de taille rapide avec StretchBlt
C'est fatigant, tout ça...
:coucou:

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