Discussion :

[Gilbert Geyer]

Bonjour Andnotor,

1) J'ai voulu tester ton code, mais comme j'utilise Delphi-5, je ne dispose pas de la routine EnsureRange et comme je suppose qu'elle s'assure que le résultat du calcul est compris entre 0 et 255 j'ai introduit la modif suivante dans DoCombine mais le BitMap-résultat est un carré noir dessiné dans l'angle supérieur gauche sur l'image de Fond 24 bits :

Code :

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

1
2
3
4
5
6
7
8
9
10
//Routine pour la combinaison du Texte et du Fond ***********************
  function DoCombine(F, B, A :byte) :byte;
  var      Res : integer;
  begin
    //(foreground_color * alpha) + (background_color * (100% - alpha)).
    //Result := EnsureRange((Round(F*A/255) + Round(B*(1-(A/255)))), 0, 255); <- EnsureRange n''existe pas sous Delphi 5
    Res := Round(F*A/255) + Round(B*(1-(A/255)));
    if Res<0 then Result:=0 else
    if Res>255 then Result:=255;
  end;

... une idée sur la cause de cette bizarrerie ? ... à moins que je ne me gourre sur le rôle que joue EnsureRange ?.

2) Concernant le principe de fonctionnement de la function TForm1.Combine(aTextBmp, aFondBmp: TBitmap): TBitmap :

C'est un peu dommage que cette fonction soit limitée aux cas où le texte est noir ($000000) ou bleu ($0000FF) et qu'elle ne traite pas le cas général de la combinaison d'une image polychrome avec une autre image polychrome (bien que l'énoncé du pb à résoudre concerne du texte bleu ou noir), ce qui la rendrait réutilisable dans des cas beaucoup plus nombreux. (j'ai un faible pour les routines "passe-partout").

A+

[Andnotor]

Tu as oublié d'assigner Result s'il est dans les limites .

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
function DoCombine(F, B, A :byte) :byte;
var
  Res :integer;
begin
  //(foreground_color * alpha) + (background_color * (100% - alpha)).
  Res := Round(F*A/255) + Round(B*(1-(A/255)));
  if Res < 0
  then Result := 0
  else if Res > 255
       then Result := 255
       else Result := Res;
end;

Malheureusement, tu ne peux pas généraliser sur des images 24 bits.

Cela fonctionne uniquement parce qu'à part le noir qui a les 3 composantes qui varient de concert, le bleu contient au moins une composante qui varie de 0 à 255 et une qui est fixe à $FF (pour la détection avec le noir).

Dans notre cas:
Le noir varie de $000000 (Noir) à $FEFEFE (Gris très clair).
Le bleu varie lui de $0000FF (bleu foncé) à $FEFEFF (bleu très clair).

On peut donc considérer que le R (ou G) est l'alpha puisqu'il varie de 0 à 255. Mais comment faire avec une couleur composite du style $35E3BD (~turquoise)

Pour des couleurs complexes, du 32 bits est obligatoire ! Mais comment générer un masque alpha depuis un document scanné
Scanner 2 fois, une fois en couleur, une fois en monochrome

[Gilbert Geyer]

Re-bonjour,

1)

Tu as oublié d'assigner Result s'il est dans les limites

... Oups, effectivement et du coup le code marche correctement : merci.

2)

Malheureusement, tu ne peux pas généraliser sur des images 24 bits.

... dommage.

par contre pour augmenter les possibilités de ré-utilisation du code ne pourrait on pas au moins faire une TForm1.Combine(aTextBmp, aFondBmp: TBitmap; clTexte : TColor): TBitmap où le paramètre clTexte pourrait prendre n'importe quelle valeur ? Resterait néanmoins le problème qu'un texte vert par exemple est formé sur ses contours par des dégradés de couleurs estompant les escaliers et que le résultat ne serait pas très "clean" vu qu'il resterait des pattes de mouche sur les contours.

Dommage aussi que c'est le texte qui soit scanné et qu'il ne s'agisse pas d'un texte de couleur quelconque sur un fond absolument blanc RGB(255,255,255) sinon on pourrait s'appuyer sur le fait que ce qui n'est pas absolument blanc c'est du texte qu'on laisse passer dans Result sinon c'est les logos-sur-fond-blac qu'on laisse passer.
Par contre ce serait jouable si c'est du texte-sur-fond-blanc-scanné on pourrait considérer que le fond du texte est blanc jusqu'à un certain niveau de gris.

A+

[Henri-gp]

Bonjour Tous

J'ai pas eu trop le temps ce jeudi,
Mais j'ai l'impression que la réponse d'y hier fonctionne.
Pour des raison de compatibilité je suis obligé de rester sur un poste NT, j'ai pas ce qu'il faut pour corriger des images, mais un collège me l'a fait(pou une image qui doit me servir de fond) et c'a FONCTIONNE.
Il m'a changer/modifier la taille et la profondeur de l'image qui doit me servir de "fondbmp" , (en plus j'ai pas vus ce qu'il a fait)

je reviens vers vous, et Merci à vous deux.

Cordialement
Henri

[Andnotor]

Gilbert

TForm1.Combine(aTextBmp, aFondBmp: TBitmap; clTexte : TColor): TBitmap

Oui mais comment déterminer clTexte par rapport au document scanné ?

Dommage aussi que c'est le texte qui soit scanné et qu'il ne s'agisse pas d'un texte de couleur quelconque sur un fond absolument blanc RGB(255,255,255) sinon on pourrait s'appuyer sur le fait que ce qui n'est pas absolument blanc c'est du texte qu'on laisse passer dans Result sinon c'est les logos-sur-fond-blac qu'on laisse passer.

Tu te retrouverais à nouveau avec une bordure blanche autour du texte comme avec k1,k2.
Le problème n'est pas de détecter les surfaces mais de déterminer la couleur de base à laquelle sera appliqué la transparence.
Le résultat devant être Anticrénelage = CouleurDeBase * Alpha.

On arriverait encore à s'en sortir avec de grosses polices (comme dans mon exemple) mais avec de petites polices, certains traits n'auront aucune portion avec un alpha à 100% et seront considérés de couleurs différentes.

[Gilbert Geyer]

Bonjour Andnotor,

Ok, vu. Je ne pensais pas utiliser Alpha mais à une logique du style "laisser passer tout ou rien" en se basant sur les couleurs de fond et en supposant :
1) que le fond original du texte soit blanc et qui scanné devient grisâtre
2) et que la vitre du scanneur utilisé soit propre.

Quand j'aurai un moment je testerai la faisabilité, on peut toujours essayer.

A+.

[Gilbert Geyer]

Re-bonjour Andnotor,

J'ai modifié ton code comme suit et remplacé Texte256.bmp par TexteTaché.bmp de même taille mais en 24 bits où j'ai remplacé sous PaintShopPro le hello noir par un 'H' orangé, un 'e' verdâtre, etc c'est à dire un Hello polychrome + un coup de pinceau en gris RGB(215,215,215) simulant la présence d'une tache de salissure sur la vitre du scanner.
Le résultat semble acceptable : sur ResultRVB.bmp la tache de salissure a disparu et le texte polychrome est bien rendu si on se contente d'un crénelage moins atténué.

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
function TForm1.Combine(aTextBmp, aFondBmp: TBitmap): TBitmap;
const    Seuil = 130; //<- Seuil de filtrage salissures vitre scanner/Texte
var
  CT    :PRGBTripleArray;  //Couleur pixel Texte
  CF    :PRGBTripleArray;  //Couleur pixel Fond
  x, y  :integer;
  MaxX, MaxY :integer;
  RT,GT,BT : byte;         //Composantes pixel Texte
 
begin
  //Force les images en 24 bits
  aTextBmp.PixelFormat := pf24bit;
  aFondBmp.PixelFormat := pf24bit;
 
  //Crée l'image résultante
  Result := TBitmap.Create;
  //Assigne l'image de fond à l'image résultante
  Result.Assign(aFondBmp);
 
  //Boucle maximum sur les plus petites Largeur/Hauteur
  MaxX := Min(aTextBmp.Width, aFondBmp.Width) -1;
  MaxY := Min(aTextBmp.Height, aFondBmp.Height) -1;
 
  for y := 0 to MaxY do
  begin
    CT := aTextBmp.ScanLine[y];
    CF := Result.ScanLine[y];
    for x := 0 to MaxX do
    begin
      //On considère comme blanc le fond du texte s'il est gris compris entre RGB(Seuil,Seuil,Seuil) et RGB(255,255,255)
      //donc si RT ou GT ou BT < Seuil on considère que c'est du texte sinon on laisse passer le logo
      RT:=CT[x].rgbtRed; GT:=CT[x].rgbtGreen; BT:=CT[x].rgbtBlue;
      if (RT<Seuil) or (GT<Seuil) or (BT<Seuil) then
      begin
            CF[x].rgbtRed   := RT;
            CF[x].rgbtGreen := GT;
            CF[x].rgbtBlue  := BT;
      end;
    end;
  end;
end;

Pour du texte scanné ça va être difficile de faire mieux en attendant de trouver une ruse de sioux pour atténuer davantage le crénelage résiduel.

A+

[Henri-gp]

Bonsoir

Je reviens vers vous après quelque jours de répits et l’essaie de vos fonctions
J’arrive parfaitement à superposer deux images à l’aide de ces fonctions, l’intégrer à l’existant est un autre problème
Mes documents sont dynamiques, d’une à seize pages.
Si je les produis en 100 ou 150 dpi ceci va relativement vite, mais peu claire au rendu, suffisant pour faire quelques ajustements
Si je les produis en 300 dpi, c’est long mais claire
Il me faut maintenant que je trouve une combine pour rendre dynamique les images que j’ai scanné afin de les accorder à la définition(100 / 150 / 300 dpi) que j’ai choisis avec Ghostscript

1/ Trouver la taille et la profondeur des images venant de Ghostscript
2/ Redimensionner les images que j’ai scanner

Si vous avez des idées, je suis preneur

Merci Gilbert, Merci Andnotor

Henri

[Andnotor]

D'après un précédent post, tu exportes depuis GhostScript en A4. J'imagine que tu scannes également en A4.

Il te suffit donc de passer par un bitmap temporaire aux dimensions de l'image GhostScript et d'utiliser StrewtchDraw pour y copier l'image scannée.

[dragonno]

Sinon juste comme ça, une question d'amateur :

C'était pas possible d'installer la librairie GraphicEX (pour travailler avec différents formats d'images), puis sur ta form de mettre un Timage, d'y déssiner dessus l'image1, puis l'image2, et ensuite de copier Timage pour en faire image3.

????

[wegadelyre]

Salut à tous,
l'exemple est vraiment très intéressant, mais juste une chose, peut ont contrôler, la superposition de façon à mettre la photo de texte à n'importe quel position dans l'image fond, par exemple au milieu ou en bas...

[Andnotor]

C'est juste un décalage sur l'image de fond : CF := Result.ScanLine[y +Offset.Y] pour la verticale et CF[x +Offset.X].rgbtRed := DoCombine(0, CF[x +Offset.X].rgbtRed, Alpha) pour l'horizontale.
Il faudra aussi prendre soin de calculer MaxX, MaxY pour qu'ils correspondent aux dimensions de l'intersection sinon la zone qui sort à droite va rentrer à gauche

[wegadelyre]

Merci

[Jipété]

Voici une démo complète.

Les images de fond et de texte ont volontairement des caractéristiques différentes :
- Fond : 250x250, 24 bits,
- Texte : 200x200, 8 bits.

Bonsoir,

Je me permets de déterrer ce vieux sujet car, tombé dessus récemment alors que je faisais des recherches (le temps qui passe n'existe pas pour Google ) sur la superposition d'images, j'ai essayé de jouer un peu avec le bout de code proposé par Andnotor, et j'avoue qu'au début j'ai pataugé, tellement que je me demandais si je verrais le bout du tunnel, jugez plutôt :


D'autant plus curieux que le défaut n'est pas le même selon qu'on compare le TImage sur la form (à gauche) avec l'affichage avec un viewer quelconque (à droite) du fichier généré par le programme.

Alors j'ai eu une idée : comme travailler avec une image dont les bords sont blancs n'est pas top pour voir exactement comment les choses se passent, je me suis dit que j'allais colorier en rose clair toute la zone blanche : je lance The Gimp et je sors deux BMP's, un en 24 bits et l'autre en 32, et là, dans un cas comme dans l'autre, la sortie est devenue bonne (voir en fin de post) !

Et voyant cela, je suis reparti du fichier d'origine et l'ai exporté depuis The Gimp en 24 bits et sous un autre nom, et là, la sortie était toujours bonne :


J'ai alors décidé de regarder les fichiers avec XnView, et voilà ce que ça donne : à gauche le fichier d'origine, au centre les 2 "bordures roses", à droite l'export en 24 bits de l'original .


C'est quand même curieux que le fichier d'origine soit vu comme un 32 bits (et mal formé, si je peux me permettre cette précision, puisque les 3 autres fichiers donnent des sorties correctes.)

Ah, pendant que j'y étais, j'ai testé l'autre bout de code (post de Gilbert du 9 janvier) du mode de fusion, résultat à droite, ça augmente l'effet d'escalier, àmha :


Un dernier mot, pour ceux qui tomberaient là-dessus et qui développeraient avec Lazarus : une seule chose à faire, commenter deux lignes et en rajouter deux.

Code :

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

1
2
3
4
//    CT := aTextBmp.ScanLine[y];
//    CF := Result.ScanLine[y];
    CT := PRGBTripleArray(aTextBmp.RawImage.GetLineStart(y));
    CF := PRGBTripleArray(Result.RawImage.GetLineStart(y));

Sans oublier les

Code :

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

1
2
  aTextBmp.BeginUpdate();
  Result.BeginUpdate();

juste avant la première boucle for et les EndUpdate à la fin des boucles.

Pas plus à dire pour le moment.

[Jipété]

- Fond : 250x250, 24 bits

Bonsoir,

Je reviens 30 secondes sur ce post pour lequel je remercie Andnotor de bien vouloir nous éclairer sur la provenance de cette information (24 bits) car voilà ce que je trouve en examinant le fichier (extrait du zip) avec XnView :


Cette valeur est confirmée par le fait que 250 x 250 x 4 (soit 32 bits) = 250000 octets et 244.19 x 1024 = 250051 octets quand un fichier en 24 bits aurait une taille, à la louche, de 188 ko.

Plus le fait que le fichier doit être mal formé car les outils Lazarus ont du mal à l'ouvrir mais il suffit de l'importer dans The Gimp et de le réexporter, quelques dizaines d'octets qui ne doivent pas être inutiles y sont rajoutés et le fichier devient correct avec Lazarus !

Merci,

[Andnotor]

Tu te poses des questions existentielles là

Quelques remarques :

1. mea culpa, l'image de fond était 32 bits. Satisfait ?
2. on s'en fout dès lors que les images étaient forcées en 24 bits avant traitement ;
3. ces fichiers avaient été générés avec Gimp ;
4. les problèmes Lazarus sont sans intérêt sur le forum Delphi.

[Jipété]

Tu te poses des questions existentielles là

Yes, mais il n'y a que comme ça que j'avance,

mea culpa, l'image de fond était 32 bits. Satisfait ?

Yes aussi, juste que je me coucherai moins bête ce soir : une hésitation levée = une nuit de vrai repos

on s'en fout dès lors que les images étaient forcées en 24 bits avant traitement ;

on s'en fout, on s'en fout, c'est toi qui le dit, mais à partir du moment où je ne passais pas la phase d'ouverture + contrôle visuel, je ne pouvais pas aller plus loin...

ces fichiers avaient été générés avec Gimp ;

Ah !
Je viens de faire un test avec mon vieux 2.8.2 : créer une nouvelle image 250x250 sans commentaires, ça me génère à l'export en 32 bits/XRGB (à quoi correspond ce "X" ? Mystère et la doc est inexistante pour cette option forcée [le choix A est grisé au premier export]) un fichier de 250138 octets, on est loin de tes 250054...
Ensuite, que j'exporte le tien ou le mien en ARGB, on retombe sur 250122 et à partir de là tout baigne.

les problèmes Lazarus sont sans intérêt sur le forum Delphi.

Oui, oh, querelle de clocher, pi d'abord je me demande bien pourquoi Delphi a un forum dédié : ça devrait être dans Pascal et pi valà.

Si tu as des stries c'est sûrement que "le lecteur bitmap" lit ton image en 24 bits alors que l'image est enregistré en 32bits

Oui, c'est ce que j'avais conclu, mais j'avais juste besoin d'une confirmation, d'une certitude que vient de m'apporter Andnotor.
EDIT : Ah ben si tu postes pi tu supprimes pendant que je réponds on va pas y arriver

Tutti va bene, passez un joyeux Noël

[Andnotor]

Je viens de faire un test avec mon vieux 2.8.2 : créer une nouvelle image 250x250 sans commentaires, ça me génère à l'export en 32 bits/XRGB (...) un fichier de 250138 octets, on est loin de tes 250054...

Ce n'est pas un forum Gimp non plus

Le fichier est plus volumineux si tu y inclus des informations de couleur. Sans cela et en exportant une nouvelle fois l'image de fond, j'obtiens 250'070 octets avec Gimp 2.8.14. Cela s'explique sans aucun doute par le passage de l'entête de V4 en V5 qui fait 16 octets de plus (la structure d'un bitmap n'est pas immuable).

Il y a clairement un problème d'offset si l'image d'origine n'est pas supportée sous Lazarus. Par exemple si la taille de l'entête est calculée par SizeOf(BITMAPV5HEADER) plutôt que récupérée dans le fichier lui-même ou peut-être en supposant qu'il y a toujours des informations de couleur.

Bref, ça fonctionne sous Delphi et c'est (pour moi bien sûr) l'essentiel !

[foetus]

Ah !
Je viens de faire un test avec mon vieux 2.8.2 : créer une nouvelle image 250x250 sans commentaires, ça me génère à l'export en 32 bits/XRGB (à quoi correspond ce "X" ? Mystère et la doc est inexistante pour cette option forcée [le choix A est grisé au premier export]) un fichier de 250138 octets, on est loin de tes 250054...

Parce qu'il n'y a pas de couche alpha Donc ce n'est pas ARGB mais XRGB pour dire 1 octet vacant.

C'est plus performant de mettre un 24 bits dans un 4 octets.

EDIT : Ah ben si tu postes pi tu supprimes pendant que je réponds on va pas y arriver

Mon explication n'était pas vraiment bonne .

Mais si tu as des stries, c'est en général parce que tu as des décalages de "couleurs" parce que tu ne prends pas un paquet ARGB/ XRGB/ RGB/ ... en entier

Tutti va bene, passez un joyeux Noël

[Jipété]

Ce n'est pas un forum Gimp non plus

Le fichier est plus volumineux si tu y inclus des informations de couleur.

Si je ne les inclus pas, j'ai un fichier inexploitable si exporté en 32 bits et OK en 24 bits (188 054 o) ! Va comprendre...
Si je les inclus, 32 bits --> 250 138 o, 24 bits --> 188 122 o, utilisables tous les deux.

Mais si tu as des stries, c'est en général parce que tu as des décalages de "couleurs" parce que tu ne prends pas un paquet ARGB/ XRGB/ RGB/ ... en entier

j'ai barré RGB car en fouillant depuis le lien d'Andnotor chez Kro on voit qu'il n'est question que de RGBQuad : ton RGB devrait s'appeler RGBD avec D pour reserveD, le "R" étant déjà pris

La grande (énorme, pour moi, mais on va la laisser en stand-by) question, c'est pourquoi et comment efg a fait une considérable utilisation des RGBTriple en D3/4/5, à voir là par exemple...

Entre ça et le PixelFormat à pf24bit/pf32bit, une chatte n'y retrouverait pas ses petits, mais je ne voulais pas vous prendre la tête avec tout ça en cette veille de fêtes.
Merci