SEAM CARVING V2
cs_pseudo3
Messages postés
268
Date d'inscription
mardi 24 juillet 2007
Statut
Membre
Dernière intervention
2 février 2021
-
19 févr. 2013 à 10:41
cs_pseudo3 Messages postés 268 Date d'inscription mardi 24 juillet 2007 Statut Membre Dernière intervention 2 février 2021 - 9 mars 2013 à 14:36
cs_pseudo3 Messages postés 268 Date d'inscription mardi 24 juillet 2007 Statut Membre Dernière intervention 2 février 2021 - 9 mars 2013 à 14:36
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/54969-seam-carving-v2
https://codes-sources.commentcamarche.net/source/54969-seam-carving-v2
9 mars 2013 à 14:36
"voilà, j'ai modifié le code pour avoir un petit message de redimensionnement de la fenêtre finale..." :
Super et de plus en rouge : on ne risque plus de ne pas le voir.
Vu toutes les améliorations je mets 10/10.
A+.
9 mars 2013 à 14:04
@cirec:
J'ai aussi modifié le thread pour ne plus presser le CPU comme un citron.
Par contre, la modif proposé ne marchait pas suivant que je compilais avec D7 ou D2009.
J'ai donc repris le code ici : http://www.delphiarea.com/downloads/ pour la gestion des threads et utilisé son TBackgroundWorker, simple mais efficace.
Je joint dans le zip le package original, mais pour mon code, le composant tbackgroundworker est crée dynamiquement, donc pas besoin de l'installer.
J'aime bien ce thread sous forme de composant car il est facile à mettre en oeuvre.
Merci pour toutes ces remarques.
A+
2 mars 2013 à 13:36
Mille excuses, vérification faite le GDIPUtil.pas est effectivement dans le Zip, mais dans ma précipitation j'ai bêtement omis de sélectionner son *.dcu dans le sous-répertoire Lib de Delphi-6 lorsque j'y ai transféré les *.dcu des autres *.pas !!!
A+.
2 mars 2013 à 13:01
je viens de re-re-télécharger le zip et il est complet !!!!!
le fichier GDIPUtil.pas se trouve bien dans le répertoire "PAS" !!!!!
c'est à toi de placer ces unités dans un répertoire dont de chemin est connu
de l'IDE.
2 mars 2013 à 11:43
Pour info : Je viens de passer en revue la totalité des démos du Zip de http://www.progdigy.com/files/gdiplus.zip mais pour certaines démos (une dizaine) j'ai eu le message [Erreur fatale] GDITEST31.dpr(9): Fichier non trouvé : 'GDIPUTIL.dcu' donc ce Zip était incomplet (scro-nieu-nieu !!!) ... mais par chance j'ai pu trouver le code de GDIPUTIL.pas ici : http://4coder.org/delphi-source-code/561/GDI_Path_Text/GdipUtils.pas.html
(ça évitera peut-être à quelqu'un de se laisser piéger).
A+.
2 mars 2013 à 10:13
A Cirec : "voici le lien pour télécharger le zip avec tout dedans sources et exemples:
http://www.progdigy.com/files/gdiplus.zip"
... J'ai téléchargé et commencé à comparer avec le GDI+ de Mitov : avec celle de chez Mitov la prise en main est difficile vu qu'il n'y a qu'une seule démo alors que la version de Progdigy est bourrée de démos : c'est donc un bon début.
A Barbichette : "Le but n'étant pas ..., mais de présenter une mini appli qui montre le principe de l'algo de Seam Carving. ...Je ne voulais pas tout mélanger." : T'as raison plus on mélange et plus on loupe l'objectif pédagogique.
A propos de "Pour l'autre remarque, je vais mettre une info sur la fenêtre principale" :
Excellente résolution car vu que ça ne saute pas aux yeux on peut se faire piéger et mettre le code illico dans la corbeille.
A+.
1 mars 2013 à 21:43
@Pseudo3 :
Pour la prise en charge des Gif, PNG, ... Je ne fais pas de la résistance, mais comme dit en commentaire du code
"Pas besoin de chercher ici un super logiciel de dessin"
Le but n'étant pas d'ouvrir tout et n'importa quoi, mais de présenter une mini appli qui montre le principe de l'algo de Seam Carving.
Pour tout dire, j'ai même hésité à utiliser un thread pour le calcul. Mais, sur de très grandes images, le temps de calcul est tellement long que ça en devenait inutilisable.
Je ne voulais pas tout mélanger. Ce qui n'empêche pas une bonne âme de rassembler tout les traitements d'images présenté sur ce site (ouverture, enregistrement, flous, torsions, contours, couleurs, dilatations...) dans une super source
Pour l'autre remarque, je vais mettre une info sur la fenêtre principale lors de la mise à jour avec la remarque de Cirec sur le thread.
a++
1 mars 2013 à 13:35
Salut,
le nombre de lignes n'est pas forcément proportionnel à la taille de l'exe.
Et heureusement ... le compilateur de delphi est intelligent, il
embarque (lie) que les procédures et fonctions qui sont utilisées dans l'application.
D'ailleurs une application de base (démo) de GDIplus fait entre 60 et 90ko !!!!
parce que sont avantage est que l'on peut l'utiliser indépendamment de la vcl.
voici le lien pour télécharger le zip avec tout dedans sources et exemples:
http://www.progdigy.com/files/gdiplus.zip
@++
1 mars 2013 à 10:23
A propos de "perso j'aime pas trop l'utilisation du "ole" pour les images
et comme, en plus, les nouvelles versions de delphi sont livrées avec les nouvelles unités pour la gestion des gif & png ... j'en ai pas le besoin. Mais si j'avais besoin de ... je me tournerai plutôt vers le GDI+"
J'utilise parfois le GDI+ de Mitov c'est à dire IGDIPlus.pas mais qui fait 17000 lignes et j'hésite donc d'en encombrer une appli juste pour pouvoir charger quelques formats supplémentaires.
Quand à l'utilisation de "ole" pour les images je viens de constater que si je charge image1.jpg avec "ole" et que, sans le modifier, je le re-sauve en image2.jpg et que je compare image2 à image1 avec PaintSopPro image2 est un peu plus petit que image1 : c'est probablement dû à une valeur de CompressionQuality inférieure au Maxi de CompressionQuality.
A+.
28 févr. 2013 à 09:59
Merci Barbichette à propos de la convention retenue pour les couleurs des zébrures.
Vu ton silence au sujet de la proposition de pouvoir en plus utiliser des fichiers *.GIF j'en déduis que ceci ne présente que peu d'intérêt ...
C'est vrai qu'avec seulement 256 couleurs de telles images sont peu nuancées.
J'en profite pour redire que pour l'instant je noterais bien 9,9/10 car il manque un détail qui ne saute pas aux yeux en voyant l'interface : Faudrait rajouter quelque part la mention "Il faut redimensionner manuellement la fenêtre "final" dans la direction qui est sélectionnée dans la barre d'outils pour obtenir un résultat" (par exemple un label, ou un Hint sur l'image "final" ou au moins un commentaire dans l'entête du code pour le 10/10. (cela évitera aux utilisateurs de se faire piéger).
A+.
27 févr. 2013 à 21:58
J'avoue que je savais que mon Thread tournait en permanence...
Je n'ai pas encore trouvé de solution simple et miraculeuse pour le stopper réellement lorsqu'il ne calcul plus et le lancer ou le relancer à la demande.
Je n'ai pas trop pousser ma réflexion sur la question car le but était de montrer le fonctionnement de l'algorithme plutôt que le fonctionnement optimisé d'un thread.
Mais, suite à ta remarque, je vais tâcher de remédier à ce souci...
A+
27 févr. 2013 à 21:53
La convention est simple, Le dégradé montre en bleu les zébrures les moins importantes (les chemins à supprimer en premier) et en rouge les plus importantes.
Dans la réalité (enfin, dans le code) chaque chemin (contenu dans FSeamsMap) prend successivement le numéro du chemin calculé (1, 2, 3, 4.....)
C'est uniquement lors de l'affichage, dans la méthode TSeamCarving.GetSeamsCarving, que je colorise chaque chemin avec la fonction 'ArcEnCiel'.
ArcEnCiel(FSeamsMap[i_in],FOri_Width);
Le deuxième paramètre indique la valeur maximal correspondant au rouge (la valeur la plus grande que peut prendre le premier paramètre).
25 févr. 2013 à 10:03
A Cirec :
Pour pouvoir charger en plus des images au format *.GIF sous Delphi-5 on peut aussi faire comme suit :
function BMPFromImgFile(const nomFichierImg: string): tBitMap; // avec axCtrls et Jpeg dans le uses
const FormatsSupportes = '.BMP.DIB.GIF.ICO.JIF.JPG..JPEG.WMF.EMF';
var OleGraphic: TOleGraphic; FS: TFileStream; ext: string; Pict: TPicture;
begin ext := UpperCase(ExtractFileExt(nomFichierImg)); if (ext '') or (pos(ext, FormatsSupportes) 0) then
begin showMessage(ext + ' = Format non supporté par BMPdeIMG');
Result := nil; EXIT;
end;
OleGraphic := TOleGraphic.Create;
FS := TFileStream.Create(nomFichierImg, fmOpenRead or fmSharedenyNone);
Pict := TPicture.create;
try
OleGraphic.LoadFromStream(FS);
Pict.Assign(OleGraphic);
Result := tBitmap.create;
with Result do
begin PixelFormat := pf32Bit;
Width := Pict.Width;
Height := Pict.Height;
Canvas.Draw(0, 0, Pict.Graphic);
end;
finally
fs.Free;
Pict.free;
OleGraphic.Free;
end;
end; // BMPFromImgFile
procedure TFrmDemoMain.Open1Click(Sender: TObject);
begin
if not OpenDialog1.Execute then exit; //< OpenDialog1 pour emplacer le OpenPictureDialog1 qui ne laisserait pas passer les *.GIF
aBMP := BMPFromImgFile(OpenDialog1.FileName);
...
suite inchangée
end;
Et ça marche sans avoir à utiliser l'unit GIFImage qui fait environ 12000 lignes.
Dommage que ça ne marche pas pour charger en plus les *.PNG et les *.TIF.
A+.
24 févr. 2013 à 14:36
Salut,
oui tu as raison ... voilà ce qui arrive quand on ne se souvient plus
de toutes les modifications qu'on apporte ...^^
ceci se résout très bien comme ceci et du coup il ne faut rien changer
au code que j'ai donné plus haut:
unit UBitmapEx;
interface
uses Classes, Graphics;
type
TBitmap = class(Graphics.TBitmap)
public
procedure Assign(Source: TPersistent); override;
end;
implementation
{ TBitmap }
procedure TBitmap.Assign(Source: TPersistent);
begin
if (Source is TIcon) or (Source is TMetafile) then
begin
// R.A.Z. les valeurs du Bitmap
Assign(nil);
width := (Source as TGraphic).Width;
Height := (Source as TGraphic).Height;
Canvas.Draw(0, 0, (Source as TGraphic));
end
else
inherited Assign(Source);
end;
end.
et il suffit d'ajouter UBitmapEx à la clause "uses" de UMain
@Barbichette:
sinon j'ai découvert un problème un peut plus important.
l'utilisation du proc sur un PC simple coeur est de 100%
et ce même quand le programme ne fait plus rien !!!!!!
j'ai donc testé sur un autre PC 4 coeurs + 4 émulés donc 8 en tout
et il tourne constamment a 13% ... ce qui correspond à
une utilisation à 100% d'un processeur sur les 8.
En regardant le code d'un peu plus près je remarque que
l'utilisation du thread n'est pas optimale ...
en effet à la fin des traitements le thread n'est pas arrêté
tu te contentes juste mettre la variable "FPause" à vrai
mais le thread lui continu son job ...
à chaque cycle du proc il est utilisé pour continuer à tester
inutilement les deux variables (Terminated & FPause)
pour t'en rendre compte il suffit:
de démarrer le proc depuis l'IDE
quand le travail est terminé
tu mets un point d'arrêt sur la ligne:
"if not FPause then"
et tu appuies plusieurs fois sur F8
pour voir que le proc ne fait plus que ça
et ça occupe toutes les ressources du proc.
Il faudrait changer toute l'organisation du thread pour
qu'à la fin des traitements il soit mis réellement en pause
avec "Suspend" et quand il y a besoin de le réactiver
avec "Resume"
@++
Cirec
23 févr. 2013 à 10:39
Pour info : Afin de pouvoir charger, en plus des *.jpg et *.bmp, les *.ico, *.emf, et *.wmf sous Delphi-5 j'ai été obligé de modifier la procedure concernée comme suit :
procedure TFrmDemoMain.Open1Click(Sender: TObject);
var
name, ext: string;
begin
if not OpenPictureDialog1.Execute then exit;
name := OpenPictureDialog1.FileName;
ext := UpperCase(ExtractFileExt(Name));
with TPicture.Create do
try
LoadFromFile(Name); if (ext '.BMP') or (ext '.JPG') or (ext = '.JPEG')
then aBMP.Assign(Graphic)
else begin
aBMP.width := Width;
aBMP.Height := Height;
aBMP.Canvas.Draw(0, 0, Graphic);
end;
finally
Free;
end;
Le chargement et le redimensionnement s'effectuent correctement avec les formats précités, par contre avec les *.ico seul le chargement s'effectue correctement. (c'était juste pour voir ce que donnerait l'agrandissement d'une icône mais ceci n'a pas d'autre intérêt).
Petite question à Barbichette au sujet des traits de couleur qui zèbrent l'"original" lors d'un redimensionnement : Quelle est la convention retenue pour la signification de leurs couleurs, car je suppose que des zébrures jaunes ou vertes ne signifient pas la mâme chose que des zébrures bleues. ???
A+.
23 févr. 2013 à 09:31
A Barbichette : Merci pour les infos concernant l'énergie d'un pixel. Puisque "Ici, on considère que le plus important dans une image, ce sont les contours" (c'est bon à savoir) j'en déduis que si j'augmente le contraste de l'image originale l'algo fonctionnera dans des conditions optimales.
Pour l'instant je noterais bien 9,9/10 car il manque un détail qui ne saute pas aux yeux : Faudrait rajouter quelque part la mention "il faut redimensionner manuellement la fenêtre "final" dans la direction qui est sélectionnée dans la barre d'outils pour obtenir un résultat" (par exemple un label, ou un Hint sur l'image "final" ou au moins un commentaire dans l'entête du code.
Mis à part ceci c'est génial.
A+.
22 févr. 2013 à 20:55
Il est marrant de voir le comportement lorsqu'il y a du texte.
Car le programme supprime les espaces entre les lettres ou les agrandit sans pour autant toucher à la forme des lettres.
22 févr. 2013 à 19:27
Dans cette méthode, l'énergie d'un pixel, c'est l'importance que l'on donne à ce pixel. Plus il est important, plus son énergie est grande.
Le problème étant de définir l'importance d'un pixel.
Ici, on considère que le plus important dans une image, ce sont les contours. C'est l'information que l’œil humain perçoit le mieux et donc, c'est l'information à maintenir dans une image.
J'utilise donc l'algorithme de Sobel (voir sur le net pour plus d'info). Cet algo renvoi justement un nombre directement en relation avec l'importance du contour.
Par contre, on part d'une image en niveaux de gris.
Une autre solution serai de se baser sur la luminosité, ou la teinte, puis chercher les contours.
Ou encore juste prendre la valeur de la luminosité comme "énergie". Plus un pixel est clair, plus il a d'énergie.
Ou encore un algorithme de reconnaissance de visage pour affecter une énergie importante aux visages et peu d'énergie à l'environnement.
Il y a sûrement encore beaucoup d'autres algorithmes de traitement d'image.
Et chacun va donner des résultats différents sur les zones à éliminer.
22 févr. 2013 à 16:13
comme toujours c'est un plaisir de voir ce genre de code ...
il y avait déjà la version 1 ... superbe, magnifique !
Maintenant on a la version 2 ... que dire de plus ... génial, peut être :D
juste un petit oubli de libération dans l'unité "USmartSeamCarving.pas"
destructor TSeamCarving.Destroy;
begin
FComputing.Terminate;
FComputing.WaitFor;
FComputing.Free;
FOriginal.Free;
FOut.Free;
FMask.Free; // Ajouté
end;
sinon je te propose une petite modification afin de pouvoir charger tous types d'images
et ne pas se limiter aux deux (Bitmap & JPG)
procedure TFrmDemoMain.Open1Click(Sender: TObject);
var
name:string;
//jpg:tjpegimage;
begin
if not OpenPictureDialog1.Execute then exit;
name:=OpenPictureDialog1.FileName;
// Modifié
with TPicture.Create do
try
LoadFromFile(Name);
aBMP.Assign(Graphic);
finally
Free;
end;
// version d'ouverture différente si BMP ou JPEG
// if lowercase(extractfileext(name))='.bmp' then
// aBmp.LoadFromFile(Name);
// if lowercase(extractfileext(name))='.jpg' then
// begin
// jpg:=tjpegimage.Create;
// jpg.LoadFromFile(name);
//
// aBmp.Assign(jpg);
// jpg.Free;
// end;
// effacement du masque
...
end;
voilà, j'ai laissé l’ancienne version en commentaire
ce qui permet de voir l'économie d'une variable et de code
ainsi su ajoutes l'unité de gestion des PNG tu pourras les charger
sans soucis ... etc
sinon c'est "perfect" du grand art ... j'attends les modifs pour noter ;)
@++
Cirec
22 févr. 2013 à 09:53
OK, merci, Ouf ça fonctionne , c'est génial.
Juste une petite question à propos du calcul des énergies : c'est quoi ce concept d'énergie ? Je connais les énergies exprimées en Joules mais pour un pixel dont je connais les valeurs R, G et B ça donne combien de Joules ?
A+.
21 févr. 2013 à 19:10
21 févr. 2013 à 10:16
Bon, ça avance : En virant des uses Types, StrUtils, et Variants, en utilisant Alpha.AlphaFormat := 1; (au lieu de AC_SRC_ALPHA;), en remplaçant if not trystrtoFloat(ETheta.Text,val) then exit par val:=strtoFloat(ETheta.Text) et en remplaçant if not trystrtoint(ERadius.Text,val) then exit par Val:= strtoint(ERadius.Text) la compilation est aussi bonne sous Delphi-5.
Mais passé ce cap il ne se passe rien lors de l'utilisation : L'image finale reste identique à l'original la seule seule qui bouge c'est la ProgressBar lorsque je clique sur l'original, et ceci même en modifiant les valeurs de Blur, Gauss et Size : mystère et boule de gomme.
Puis il y a un truc qui m'intrigue : Pourquoi avoir supprimé la possibilité de fixer les valeurs de Crop comme c'était le cas dans la version 1 ??? Mais bon je suppose que ce rôle est normalement joué par Size dans la version 2.
A+.
21 févr. 2013 à 08:30
Super ..
la compilation est bonne sous 2007.
Merci
20 févr. 2013 à 19:42
En fait, les évènements OnCreate et OnShow ne sont pas gérés de la même façon entre delphi 7 et delphi 2009. Du moins avec les fenêtres MDI parent et enfants.
Donc, dans mon projet, sous 2009, l'objet existe déjà alors qu'avec D7, il n'était pas encore créé...
20 févr. 2013 à 09:41
Merci Barbichette pour AC_SRC_ALPHA=1 visiblement t'as eu plus de chance que moi avec Google et du coup j'ai pu avancer.
Mais manque de bol en lançant l'appli j'ai eu une violation d'accès dans la procédure suivante de l'unit UPict :
procedure TForm1.FormConstrainedResize(Sender: TObject; var MinWidth, MinHeight,
MaxWidth, MaxHeight: Integer);
begin
if Main.SeamCarving.Direction=Dir_Horizontal then <- Ligne pointée par le compilo suite à la V.A
Je pense que ça provient du fait que nous n'utilisons pas les mêmes versions de Delphi.
A+.
19 févr. 2013 à 15:29
Dommage avec Delphy7 l'erreur suivante s'affiche
---------------------------
Notification d'une exception du débogueur
---------------------------
Le projet SeamsCarving.exe a provoqué une classe d'exception EReadError
avec le message 'La propriété ExplicitLeft n'existe pas'.
Processus stoppé. Utilisez Pas-à-pas ou Exécuter pour continuer.
---------------------------
19 févr. 2013 à 10:41
J'ai voulu tester mais comme j'utilise Delphi-5 j'ai un petit problème de message d'erreur avec la procedure TFrmDemoMain.ChangeSize(sender:TObject;x, y: integer);
var
Alpha:TBlendFunction;
begin
FormFinal.Image.Picture.Bitmap.Assign(SeamCarving.GetFinal(x,y));
FormOriginal.Image.Picture.Bitmap.Assign(SeamCarving.GetSeamsCarving(x,y));
if HideMask.Checked then exit;
Alpha.BlendOp := AC_SRC_OVER;
Alpha.BlendFlags := 0;
Alpha.SourceConstantAlpha := $A0;
Alpha.AlphaFormat := AC_SRC_ALPHA; //<- [Erreur] UMain.pas(109): Identificateur non déclaré : 'AC_SRC_ALPHA'
Quelle est donc la valeur de cette constante AC_SRC_ALPHA ???
A+.