cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 1 déc. 2011 à 13:48
Re-Bonjour,
Ouf! Merci beaucoup, cela a enfin marché correctement.
A+.
cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 1 déc. 2011 à 13:34
Re-bonjour,
Merci Cirec : Oups je ne l'avais pas vu. Je vais donc re-faire la manip.
A+.
Cirec
Messages postés3833Date d'inscriptionvendredi 23 juillet 2004StatutModérateurDernière intervention18 septembre 202250 1 déc. 2011 à 12:31
@Pseudo3:
Salut,
oui regarde en haut de page juste en dessous de l'inscription "Information sur la source" il y a un lien que pour toi "Modifier ce code"
tu cliques dessus et tu suis les instructions ... ça devrait fonctionner
cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 1 déc. 2011 à 12:06
Re-bonjour,
Cela fait trois fois de suite que j'ai procédé à la mise à jour du code ici, mais en téléchargeant le Zip d'ici vers chez moi je retrouve chaque fois l'ancien code non mis à jour !!!
A cet effet je suis passé par "Ajouter un nouveau code" puis cliqué sur le "modifier" en bleu, etc, jusqu'au bouton "Terminer" de la fenêtre où l'on renseigne les mots-clefs : Y'a-t-il une façon plus efficace pour réaliser avec succès une mise à jour ???
A+.
cs_cantador
Messages postés4720Date d'inscriptiondimanche 26 février 2006StatutModérateurDernière intervention31 juillet 202113 30 nov. 2011 à 20:20
les logiciels experts ne sont là que pour rendre compréhensible un code illisible...
ils font l'indentation, mais font aussi une multitude de choses en plus comme par exemple,le rangement des composants sur plusieurs niveaux,
leurs remplacements automatiques dans le code, la détection automatique en cas de changement de valeur d'une varaiable etc.
Pour les sous-fonctions et procédures, oui c'est très bien..
je les utilisent souvent.
une petite note d'encouragement pour pseudo3 7/10
Caribensila
Messages postés2527Date d'inscriptionjeudi 15 janvier 2004StatutMembreDernière intervention16 octobre 201918 30 nov. 2011 à 19:24
Bonjour,
Je n'ai pas encore regardé le code, mais je suis 100% d'accord avec PSEUDO3 en ce qui concerne les sous-routines encapsulées.
En effet, si cette sous-routine n'est utilisée QUE dans la routine qui la contient, je trouve que le fait de l'encapsuler simplifie la compréhension globale de l'unité où elle se trouve en fractionnant le code par familles de raisonnement. D'autre part, côté optimisation, cela évite des variables globales ou le passage de paramètres (comme l'indique PSEUDO3). Et cela ne fait pas "crade" si on prend soin de l'indentation et de la présentation du code. En tout cas, cette façon de faire dépasse largement le seul aspect esthétique. Son seul défaut étant qu'elle ne soit pas très répandue et qu'elle bouleverse un peu nos habitudes. Mais « l'habitude, c'est l'animal en nous! ». :p
Ton en-tête est très claire et donne envie de se plonger dans ton code car sa compréhension en est grandement facilitée.
En revanche, je trouve que de penser que les logiciels experts ne sont là que pour rendre compréhensible un code illisible à ceux qui lui portent un peu d'intérêt est très discutable. Le devoir de clarté se trouve toujours du côté de l'auteur, non? ;)
cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 30 nov. 2011 à 11:33
Bonjour,
A Cantador : "Le squelette est plus intéressant, car il permet de voir les articulations entre les begin et les end et quand ça se complique, c'est mieux.
Certains experts comme Formatter, Gexperts, FastCube etc indentent automatiquement le code de cette manière" :
... Bonne nouvelle si des logiciels experts permettent de le faire automatiquement alors je suis tranquille.
Pour ma part j'essaye toujours de raccourcir autant que possible le squelette sous forme d'une simple gare de triage qui renvoie le boulot à des sous-fonctions et des sous-procédures encapsulées et chaque sous-routine forme une "unité de pensée" ... et en plus, l'utilisation de sous-routines encapsulées permet d'éviter d'avoir à passer des paramètres via la pile ce qui serait nécessaire si les sous-routines n'étaient pas encapsulées.
... Ceci étant, chacun a ses habitudes.
A+.
cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 29 nov. 2011 à 11:59
Bonjour,
1) Tu dis "J'aurais écris function BmpFromImgFile ou mieux ImgFile_To_Bmp (Mais bon après ca c'est en fonction de ses habitudes)".
... effectivement j'ai une petite préférence pour des noms français.
... mais pour te faire plaisir je vais retenir ImgFile_To_Bmp() pour l'une et BMP_To_JPEG() pour l'autre.
2) Tu dis "mettre des fonctions dans une fonction : C'est à mon gout une mauvaise habitude (Imaginons que tu veuilles rajouter d'autres filtres qui utilisent certaines de ces fonctions, tu seras obligé de modifier ton code) et je trouve cela moins simple au niveau de la compréhension"
... Dans le cas présent les deux sous-procédures ComptagesPlageDominante et GSPixel sont trop spécififiques au cas particulier des yeux rouges pour pouvoir être utilisables dans un autre but excepté les trois lignes du début :
Scan := Scan0;
Inc(Scan, y*MLS + x*Bpp);
with PRGBQuad(scan)^ do
3) Tu dis "Pour les pointeurs : tu as certaines conversions que tu fais qui pourrait être optimisé en utilisant ces derniers d'ou ma remarque".
... Tu as très certainement raison, mais vu que la surface de l'iris d'un oeil est généralement relativement petite le résultat s'obtient de façon quasi-instantanée ... mais si tu as une proposition de modification à effectuer on peut toujours en discuter.
4)Pour ce qui est d'une en-tête, voici déjà celle que j'envisage d'ajouter dans le code :
// PRINCIPE utilisé pour corriger l'effet "YEUX ROUGES" :
// Comme un flash produit le rougissement des yeux chez les humains mais
// peut aussi modifier chez des animaux un changement de la couleur de l'iris
// (Exemple : en vert chez les chats), la procedure "CorrYeuxRouges" :
// - Commence par faire un tour de reconnaissance par comptages dans la zone
// circulaire du Diamètre passé en paramètre en vue d'identifier la plage de
// couleur dominante. Ceci est réalisé par la sous-procedure encapsulée
// "ComptagesPlageDominante" qui convertit les valeurs RGB en HSV (Hue,
// Saturation, Valeur), Hue étant la teinte du pixel.
// Hue pouvant varier de 0 à 360, on scinde en six plages de comptages
// (tableau ptsHue[]) dans l'ordre à dominante Rouge, Jaune, Verte, Cyan,
// Bleue, Magenta. Dès le stade de ce comptage on évite de comptabiliser les
// pixels des zones claires, des zones blanchâtres (blanc de l'oeil...) ou
// grisées (reflets...), et des zones sombres (cils...) c'est à dire des
// zones à préserver.
// - Ensuite une boucle cherche laquelle de ces 6 plages est la plage de
// couleur dominante, et :
// . si aucune plage n'est dominante c'est que la zone passée en paramètre
// n'est soit pas oeil, soit il s'agit d'une zone à préserver.
// . si c'est une plage autre que la Rouge un dialogue prévient "Cet oeil
// n'est pas rouge mais à dominante Verte" par exemple et demande de
// confimer s'il faut corriger cette dominante.
// . par contre si c'est la plage du Rouge on y corrige illico le rouge.
// - Les corrections des couleurs sont réalisées par la sous-procédure
// encapsulée "GSPixel". Celle-ci laisse intacts les pixels des zones à
// préserver, par contre si elle rencontre un pixel correspondant à la plage
// dominante à corriger, la sous-procédure en divise, selon les cas, une ou
// deux de ses composantes (R,G,B) par deux ou par trois (c'est moins brutal
// que de les ramener à zéro).
Sur ce, je vais attendre quelques jours pour voir si quelqu'un d'autre a des souhaits de modification pour regrouper le tout en une seule mise à jour.
A+.
cs_cantador
Messages postés4720Date d'inscriptiondimanche 26 février 2006StatutModérateurDernière intervention31 juillet 202113 29 nov. 2011 à 11:20
J'ai pris l'habitude de coller un max d'instructions sur une même ligne pour avoir une visibilité quasi-globale sur une procédure ou une fonction car avec une seule instruction par ligne je me retrouve rapidement avec une sorte de squelette sans fin.
Ce n'est pas une bonne méthode..
Le squelette est plus intéressant, car il permet de voir les articulations entre les begin et les end et quand ça se complique, c'est mieux.
Certains experts comme Formatter, Gexperts, FastCube etc indentent automatiquement le code de cette manière, ce qui au final est plus pratique car du coup on ne pose plus de questions..
Une fois paramétré (les décalages, commentaires etc) on clique et le code se présente toujours de la même façon.
Il faut aussi noter que cette écriture est devenue un standard chez les professionnels.
Mon chat fait la tête car il n'a plus ses beaux yeux verts..
moi en revanche, sans mes yeux rouges, je suis beaucoup plus sémillant!
Autant pour moi : Disons que le nom de cette fonction est mal choisie function BMPdeIMG d'ou ma remarque sur l'incohérence :).
J'aurais écris function BmpFromImgFile ou mieux ImgFile_To_Bmp (Mais bon après ca c'est en fonction de ses habitudes).
Pour le fait de mettre des fonctions dans une fonction : C'est à mon gout une mauvaise habitude (Imaginons que tu veuilles rajouter d'autres filtres qui utilisent certaines de ces fonctions, tu seras obligé de modifier ton code) et je trouve cela moins simple au niveau de la compréhension.
Pour les pointeurs : tu as certaines conversions que tu fais qui pourrait être optimisé en utilisant ces derniers d'ou ma remarque. Voili voilou
cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 28 nov. 2011 à 15:38
Bonjour,
Tu dis "Ton indentation est peu orthodoxe et ne facilite malheureusement pas la lecture (Ce qui explique peut etre le peu de commentaires)"
... J'ai pris l'habitude de coller un max d'instructions sur une même ligne pour avoir une visibilité quasi-globale sur une procédure ou une fonction car avec une seule instruction par ligne je me retrouve rapidement avec une sorte de squelette sans fin.
Tu dis "function JPEGdeBMP(const BMP : tBitMap) : TJPEGImage;
Il y a une incohérence, la seconde fonction devrait s'écrite
BMPdeJPEG et non l'inverse".
... Pas d'accord, pour moi "JPEGdeBMP" signifie JPEG de BMP dans le sens où "de" = "du".
... Mais je suppose que tu voudrais que cela s'appelle, non BMPdeJPEG, mais BmpToJpeg. Non ?
Tu dis "Ton code pourrait être optimisé en utilisant des pointeurs"
... mais PRGBQuad(scan)^ c'est bien de l'utilisation de pointeurs, Non ?
Tu dis "Des fonctions (procédures) dans des fonctions (procédures) ? Non non non ca fait crade"
... J'encapsule des sous-procédures ou des sous-fonctions dans des routines pour éviter l'éparpillement de sorte que si cela me prend de déplacer la routine dans une autre unité je déplace le tout en un seul bloc.
Tu dis "Il manque une en-tête ou au moins un fichier texte,pdf ou doc à coté dans laquelle le principe utilisé est expliqué".
... J'avais pensé que les nombreux commentaires présents dans la procedure CorrYeuxRouges() suffiraient mais effectivement cela n'empêche pas de résumer le principe dans une en-tête : Je note en attendant les commentaires d'autres.
Tu dis "Bon après ce commentaire qui peut semblé cinglant (c'est pas le but hein) ce source est loin d'être inintéressant bien au contraire".
... On dit bien "qui aime bien, châtie bien."
Salut. Tu veux des commentaires ? Bon ben je m'y colle lol.
Ton indentation est peu orthodoxe et ne facilite malheureusement pas la lecture (Ce qui explique peut etre le peu de commentaires).
Par exemple
procedure RGBtoHSV(const R,G,B: byte; var H,S,V: integer); // RGB dans 0..255, H dans 0..360°, S et V dans 0..255
var Delta,Mini : integer;
begin Mini := min(R, min(G,B));
V := max(R, max(G,B));
Delta := V - Mini;
En standard devient
procedure RGBtoHSV(const R,G,B: byte; var H,S,V: integer);
//RGB dans 0..255, H dans 0..360°, S et V dans 0..255
var
Delta,Mini : integer;
begin
Mini := min(R, min(G,B));
V := max(R, max(G,B));
Delta := V - Mini;
....
End;
Pareil
case hh of
0: begin Ri := V; Gi := t ; Bi := p; end;
Devrait s'écrire
case hh of
0: begin
Ri := V;
Gi := t ;
Bi := p;
end;
// Ouvrir un fichier *.BMP, *DIB, *.GIF, *.ICO, *.JIF, *.JPG, *.WMF, ou *.EMF'
// et le récupérer sous forme d'un BitMap :
function BMPdeIMG(const nomFichierImg : string) : tBitMap;
// Convertir un BitMap en un *.JPG
function JPEGdeBMP(const BMP : tBitMap) : TJPEGImage;
Il y a une incohérence, la seconde fonction devrait s'écrite
BMPdeJPEG et non l'inverse.
Ton code pourrait être optimisé en utilisant des pointeurs : Pas envie de m'y coller mais bon ca devrait etre une habitude quand on travaille sur les images.
SelectObject, DeleteObject : pourquoi utiliser des API pour faire ça ?
Des fonctions (procédures) dans des fonctions (procédures) ? Non non non ca fait crade, ca sert à rien et si les déclarations private, public, protected existent c'est pas pour rien.
Il manque une en-tête ou au moins un fichier texte,pdf ou doc à coté dans laquelle le principe utilisé est expliqué.
Bon après ce commentaire qui peut semblé cinglant (c'est pas le but hein) ce source est loin d'être inintéressant bien au contraire.
cs_pseudo3
Messages postés268Date d'inscriptionmardi 24 juillet 2007StatutMembreDernière intervention 2 février 20211 28 nov. 2011 à 11:19
Zzzzzzzz Zzzzzzz: Silence radio ?
Déjà 50 téléchargements et pas un seul commentaire !!!???
Cela m'étonnerait que mon truc ne soit pas perfectible.
1 déc. 2011 à 13:48
Ouf! Merci beaucoup, cela a enfin marché correctement.
A+.
1 déc. 2011 à 13:34
Merci Cirec : Oups je ne l'avais pas vu. Je vais donc re-faire la manip.
A+.
1 déc. 2011 à 12:31
Salut,
oui regarde en haut de page juste en dessous de l'inscription "Information sur la source" il y a un lien que pour toi "Modifier ce code"
tu cliques dessus et tu suis les instructions ... ça devrait fonctionner
1 déc. 2011 à 12:06
Cela fait trois fois de suite que j'ai procédé à la mise à jour du code ici, mais en téléchargeant le Zip d'ici vers chez moi je retrouve chaque fois l'ancien code non mis à jour !!!
A cet effet je suis passé par "Ajouter un nouveau code" puis cliqué sur le "modifier" en bleu, etc, jusqu'au bouton "Terminer" de la fenêtre où l'on renseigne les mots-clefs : Y'a-t-il une façon plus efficace pour réaliser avec succès une mise à jour ???
A+.
30 nov. 2011 à 20:20
ils font l'indentation, mais font aussi une multitude de choses en plus comme par exemple,le rangement des composants sur plusieurs niveaux,
leurs remplacements automatiques dans le code, la détection automatique en cas de changement de valeur d'une varaiable etc.
Pour les sous-fonctions et procédures, oui c'est très bien..
je les utilisent souvent.
une petite note d'encouragement pour pseudo3 7/10
30 nov. 2011 à 19:24
Je n'ai pas encore regardé le code, mais je suis 100% d'accord avec PSEUDO3 en ce qui concerne les sous-routines encapsulées.
En effet, si cette sous-routine n'est utilisée QUE dans la routine qui la contient, je trouve que le fait de l'encapsuler simplifie la compréhension globale de l'unité où elle se trouve en fractionnant le code par familles de raisonnement. D'autre part, côté optimisation, cela évite des variables globales ou le passage de paramètres (comme l'indique PSEUDO3). Et cela ne fait pas "crade" si on prend soin de l'indentation et de la présentation du code. En tout cas, cette façon de faire dépasse largement le seul aspect esthétique. Son seul défaut étant qu'elle ne soit pas très répandue et qu'elle bouleverse un peu nos habitudes. Mais « l'habitude, c'est l'animal en nous! ». :p
Ton en-tête est très claire et donne envie de se plonger dans ton code car sa compréhension en est grandement facilitée.
En revanche, je trouve que de penser que les logiciels experts ne sont là que pour rendre compréhensible un code illisible à ceux qui lui portent un peu d'intérêt est très discutable. Le devoir de clarté se trouve toujours du côté de l'auteur, non? ;)
30 nov. 2011 à 11:33
A Cantador : "Le squelette est plus intéressant, car il permet de voir les articulations entre les begin et les end et quand ça se complique, c'est mieux.
Certains experts comme Formatter, Gexperts, FastCube etc indentent automatiquement le code de cette manière" :
... Bonne nouvelle si des logiciels experts permettent de le faire automatiquement alors je suis tranquille.
Pour ma part j'essaye toujours de raccourcir autant que possible le squelette sous forme d'une simple gare de triage qui renvoie le boulot à des sous-fonctions et des sous-procédures encapsulées et chaque sous-routine forme une "unité de pensée" ... et en plus, l'utilisation de sous-routines encapsulées permet d'éviter d'avoir à passer des paramètres via la pile ce qui serait nécessaire si les sous-routines n'étaient pas encapsulées.
... Ceci étant, chacun a ses habitudes.
A+.
29 nov. 2011 à 11:59
1) Tu dis "J'aurais écris function BmpFromImgFile ou mieux ImgFile_To_Bmp (Mais bon après ca c'est en fonction de ses habitudes)".
... effectivement j'ai une petite préférence pour des noms français.
... mais pour te faire plaisir je vais retenir ImgFile_To_Bmp() pour l'une et BMP_To_JPEG() pour l'autre.
2) Tu dis "mettre des fonctions dans une fonction : C'est à mon gout une mauvaise habitude (Imaginons que tu veuilles rajouter d'autres filtres qui utilisent certaines de ces fonctions, tu seras obligé de modifier ton code) et je trouve cela moins simple au niveau de la compréhension"
... Dans le cas présent les deux sous-procédures ComptagesPlageDominante et GSPixel sont trop spécififiques au cas particulier des yeux rouges pour pouvoir être utilisables dans un autre but excepté les trois lignes du début :
Scan := Scan0;
Inc(Scan, y*MLS + x*Bpp);
with PRGBQuad(scan)^ do
3) Tu dis "Pour les pointeurs : tu as certaines conversions que tu fais qui pourrait être optimisé en utilisant ces derniers d'ou ma remarque".
... Tu as très certainement raison, mais vu que la surface de l'iris d'un oeil est généralement relativement petite le résultat s'obtient de façon quasi-instantanée ... mais si tu as une proposition de modification à effectuer on peut toujours en discuter.
4)Pour ce qui est d'une en-tête, voici déjà celle que j'envisage d'ajouter dans le code :
// PRINCIPE utilisé pour corriger l'effet "YEUX ROUGES" :
// Comme un flash produit le rougissement des yeux chez les humains mais
// peut aussi modifier chez des animaux un changement de la couleur de l'iris
// (Exemple : en vert chez les chats), la procedure "CorrYeuxRouges" :
// - Commence par faire un tour de reconnaissance par comptages dans la zone
// circulaire du Diamètre passé en paramètre en vue d'identifier la plage de
// couleur dominante. Ceci est réalisé par la sous-procedure encapsulée
// "ComptagesPlageDominante" qui convertit les valeurs RGB en HSV (Hue,
// Saturation, Valeur), Hue étant la teinte du pixel.
// Hue pouvant varier de 0 à 360, on scinde en six plages de comptages
// (tableau ptsHue[]) dans l'ordre à dominante Rouge, Jaune, Verte, Cyan,
// Bleue, Magenta. Dès le stade de ce comptage on évite de comptabiliser les
// pixels des zones claires, des zones blanchâtres (blanc de l'oeil...) ou
// grisées (reflets...), et des zones sombres (cils...) c'est à dire des
// zones à préserver.
// - Ensuite une boucle cherche laquelle de ces 6 plages est la plage de
// couleur dominante, et :
// . si aucune plage n'est dominante c'est que la zone passée en paramètre
// n'est soit pas oeil, soit il s'agit d'une zone à préserver.
// . si c'est une plage autre que la Rouge un dialogue prévient "Cet oeil
// n'est pas rouge mais à dominante Verte" par exemple et demande de
// confimer s'il faut corriger cette dominante.
// . par contre si c'est la plage du Rouge on y corrige illico le rouge.
// - Les corrections des couleurs sont réalisées par la sous-procédure
// encapsulée "GSPixel". Celle-ci laisse intacts les pixels des zones à
// préserver, par contre si elle rencontre un pixel correspondant à la plage
// dominante à corriger, la sous-procédure en divise, selon les cas, une ou
// deux de ses composantes (R,G,B) par deux ou par trois (c'est moins brutal
// que de les ramener à zéro).
Sur ce, je vais attendre quelques jours pour voir si quelqu'un d'autre a des souhaits de modification pour regrouper le tout en une seule mise à jour.
A+.
29 nov. 2011 à 11:20
Ce n'est pas une bonne méthode..
Le squelette est plus intéressant, car il permet de voir les articulations entre les begin et les end et quand ça se complique, c'est mieux.
Certains experts comme Formatter, Gexperts, FastCube etc indentent automatiquement le code de cette manière, ce qui au final est plus pratique car du coup on ne pose plus de questions..
Une fois paramétré (les décalages, commentaires etc) on clique et le code se présente toujours de la même façon.
Il faut aussi noter que cette écriture est devenue un standard chez les professionnels.
Mon chat fait la tête car il n'a plus ses beaux yeux verts..
moi en revanche, sans mes yeux rouges, je suis beaucoup plus sémillant!
29 nov. 2011 à 09:44
Autant pour moi : Disons que le nom de cette fonction est mal choisie function BMPdeIMG d'ou ma remarque sur l'incohérence :).
J'aurais écris function BmpFromImgFile ou mieux ImgFile_To_Bmp (Mais bon après ca c'est en fonction de ses habitudes).
Pour le fait de mettre des fonctions dans une fonction : C'est à mon gout une mauvaise habitude (Imaginons que tu veuilles rajouter d'autres filtres qui utilisent certaines de ces fonctions, tu seras obligé de modifier ton code) et je trouve cela moins simple au niveau de la compréhension.
Pour les pointeurs : tu as certaines conversions que tu fais qui pourrait être optimisé en utilisant ces derniers d'ou ma remarque. Voili voilou
28 nov. 2011 à 15:38
Tu dis "Ton indentation est peu orthodoxe et ne facilite malheureusement pas la lecture (Ce qui explique peut etre le peu de commentaires)"
... J'ai pris l'habitude de coller un max d'instructions sur une même ligne pour avoir une visibilité quasi-globale sur une procédure ou une fonction car avec une seule instruction par ligne je me retrouve rapidement avec une sorte de squelette sans fin.
Tu dis "function JPEGdeBMP(const BMP : tBitMap) : TJPEGImage;
Il y a une incohérence, la seconde fonction devrait s'écrite
BMPdeJPEG et non l'inverse".
... Pas d'accord, pour moi "JPEGdeBMP" signifie JPEG de BMP dans le sens où "de" = "du".
... Mais je suppose que tu voudrais que cela s'appelle, non BMPdeJPEG, mais BmpToJpeg. Non ?
Tu dis "Ton code pourrait être optimisé en utilisant des pointeurs"
... mais PRGBQuad(scan)^ c'est bien de l'utilisation de pointeurs, Non ?
Tu dis "Des fonctions (procédures) dans des fonctions (procédures) ? Non non non ca fait crade"
... J'encapsule des sous-procédures ou des sous-fonctions dans des routines pour éviter l'éparpillement de sorte que si cela me prend de déplacer la routine dans une autre unité je déplace le tout en un seul bloc.
Tu dis "Il manque une en-tête ou au moins un fichier texte,pdf ou doc à coté dans laquelle le principe utilisé est expliqué".
... J'avais pensé que les nombreux commentaires présents dans la procedure CorrYeuxRouges() suffiraient mais effectivement cela n'empêche pas de résumer le principe dans une en-tête : Je note en attendant les commentaires d'autres.
Tu dis "Bon après ce commentaire qui peut semblé cinglant (c'est pas le but hein) ce source est loin d'être inintéressant bien au contraire".
... On dit bien "qui aime bien, châtie bien."
A+.
28 nov. 2011 à 13:35
Ton indentation est peu orthodoxe et ne facilite malheureusement pas la lecture (Ce qui explique peut etre le peu de commentaires).
Par exemple
procedure RGBtoHSV(const R,G,B: byte; var H,S,V: integer); // RGB dans 0..255, H dans 0..360°, S et V dans 0..255
var Delta,Mini : integer;
begin Mini := min(R, min(G,B));
V := max(R, max(G,B));
Delta := V - Mini;
En standard devient
procedure RGBtoHSV(const R,G,B: byte; var H,S,V: integer);
//RGB dans 0..255, H dans 0..360°, S et V dans 0..255
var
Delta,Mini : integer;
begin
Mini := min(R, min(G,B));
V := max(R, max(G,B));
Delta := V - Mini;
....
End;
Pareil
case hh of
0: begin Ri := V; Gi := t ; Bi := p; end;
Devrait s'écrire
case hh of
0: begin
Ri := V;
Gi := t ;
Bi := p;
end;
// Ouvrir un fichier *.BMP, *DIB, *.GIF, *.ICO, *.JIF, *.JPG, *.WMF, ou *.EMF'
// et le récupérer sous forme d'un BitMap :
function BMPdeIMG(const nomFichierImg : string) : tBitMap;
// Convertir un BitMap en un *.JPG
function JPEGdeBMP(const BMP : tBitMap) : TJPEGImage;
Il y a une incohérence, la seconde fonction devrait s'écrite
BMPdeJPEG et non l'inverse.
Ton code pourrait être optimisé en utilisant des pointeurs : Pas envie de m'y coller mais bon ca devrait etre une habitude quand on travaille sur les images.
SelectObject, DeleteObject : pourquoi utiliser des API pour faire ça ?
Des fonctions (procédures) dans des fonctions (procédures) ? Non non non ca fait crade, ca sert à rien et si les déclarations private, public, protected existent c'est pas pour rien.
Il manque une en-tête ou au moins un fichier texte,pdf ou doc à coté dans laquelle le principe utilisé est expliqué.
Bon après ce commentaire qui peut semblé cinglant (c'est pas le but hein) ce source est loin d'être inintéressant bien au contraire.
28 nov. 2011 à 11:19
Déjà 50 téléchargements et pas un seul commentaire !!!???
Cela m'étonnerait que mon truc ne soit pas perfectible.
A+.