Discussion :

[Jipété]

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,

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 : StretchXBR_new.zip

Ouvrez les fichiers et cherchez "jpt".

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

Code :

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

1
2
3
4
5
{$IFDEF LINUX}
// actions pour le pingouin
{$ELSE}
// actions pour la fenêtre
{$ENDIF}

Il faut arriver jusque là :

[BeanzMaster]

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

[Jipété]

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

Tes désirs sont des ordres : full_StretchXBRV4.zip

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 !

[BeanzMaster]

Merci

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

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

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+

[Jipété]

Impossible de tester

Code :

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

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.
Bref... : StretchXBR_V4.res.txt
Tu enlèveras ".txt".

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.

[der§en]

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

[Roland Chastain]

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 Batch :

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

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

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

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

[Jipété]

Bonjour Roland (et les copains),

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).

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 ), l'ai ouvert (bouton [pas visible sur la copie d'écran] à droite ), ai réglé le zoom à 200 % (il fonctionne avec les flèches du clavier, heureusement), et clic sur le gros bouton central et zou !



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

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 : xbr.zip

Enjoy, et bon week-end.


PS :

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...

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

Tu nous raconteras, tu mets ma curiosité à rude épreuve,

[Roland Chastain]

Merci Jipété.

(je pensais à l'autre, dommage )

Désolé pour la fausse joie.

[BeanzMaster]

Ç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.
Bref... : StretchXBR_V4.res.txt
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 :

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

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 :

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

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 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]

[Jipété]

Yop !

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 :

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

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 :

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 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 :



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

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

[BeanzMaster]

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 :



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

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.

[Jipété]

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à :

Tes désirs sont des ordres : full_StretchXBRV4.zip

voilà :

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,

[BeanzMaster]

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

mais comment se fait-il que, par exemple

Code :

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

Scan0 := BmpS.ScanLine[0];

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

[Jipété]

mais comment se fait-il que, par exemple

Code :

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

Scan0 := BmpS.ScanLine[0];

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

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 ?

[BeanzMaster]

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



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

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

Bon après midi

A+

[Jipété]

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 :

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

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

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

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...


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

[Jipété]

Il faut arriver jusque là :

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 :

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
    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 :

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

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) :


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

[BeanzMaster]

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

Image avec StrechXBR4 chez moi


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+

[Jipété]

--snip--

Ouais ouais ouais ouais-ouais...

De mon côté, j'ai décoché , 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 :

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

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...