J'ai réussi à compiler le plugin refocus pour GIMP 2.0.0.
Ce plugin augmente la netteté par un algorithme de convolution meilleur
que la méthode du masque flou (unsharp mask).
On Fri, 16 Apr 2004 22:30:25 +0200, Jean-Louis Hamel wrote:
Sous Windows, il plantait effectivement en fin de calcul lorsque l'une des dimensions de l'image n'était pas multiple de 64
Sous Linux, il plante lorsque la boîte de dialogue lance le traitement de l'image complète. J'ai fait des tests avec des sélections, et effectivement, le plantage se produit lorsque la sélection est presque aussi grande que l'image, moins quelques dizaines de pixels.
Si le problème ne se produit pas sur ta Mandrake, peut-être est-ce parce que tu y as installé la version précompilée "Mandrake". Mon PC est sur Redhat 9, et j'ai compilé Gimp **1.2.5** depuis les sources.
Je suspecte que ce problème (c'est un débordement de tampon mémoire) pourrait également provoquer un plantage sous Linux. [...]
Voici la modif à faire: dans tilebuf.c il faut insérer après la ligne 232 l'instruction:
Merci pour ces détails, je vais tester.
pour imprimer je me demande encore si c'est mieux qu'un "sharpen" classique ... A mon avis, c'est justement en impression que je le trouve supérieur.
Pour le Web, avec de petites images, on obtient de bons résultats en diminuant le rayon (0,8 par exemple).
Personnellement je teste d'abord un gauss à 0.9 et tout le reste à 0, sauf le noise à 0.01. Puis, si ce n'est pas satisfaisant, je joue sur les trois autres paramètres pour atténuer les artefacts.
Sinon, j'ai peu de différences entre une matrice 3x3 et 10x10. Pourtant dans la théorie l'algo est sensé en dépendre assez notablement.
As-tu aussi constaté cela ?
En espérant que çà aide...
Bien sûr !
-- Christian Tsotras - ICQ:37288308 http://www.photo.net/shared/community-member?user_id)5376
On Fri, 16 Apr 2004 22:30:25 +0200, Jean-Louis Hamel wrote:
Sous Windows, il plantait effectivement en fin de calcul lorsque l'une
des dimensions de l'image n'était pas multiple de 64
Sous Linux, il plante lorsque la boîte de dialogue lance le traitement de
l'image complète. J'ai fait des tests avec des sélections, et
effectivement, le plantage se produit lorsque la sélection est presque
aussi grande que l'image, moins quelques dizaines de pixels.
Si le problème ne se produit pas sur ta Mandrake, peut-être est-ce parce
que tu y as installé la version précompilée "Mandrake". Mon PC est sur
Redhat 9, et j'ai compilé Gimp **1.2.5** depuis les sources.
Je suspecte que ce problème (c'est un débordement de tampon mémoire)
pourrait également provoquer un plantage sous Linux.
[...]
Voici la modif à faire: dans tilebuf.c il faut insérer après la ligne
232 l'instruction:
Merci pour ces détails, je vais tester.
pour imprimer je me demande encore si c'est mieux qu'un "sharpen"
classique ...
A mon avis, c'est justement en impression que je le trouve supérieur.
Pour le Web, avec de petites images, on obtient de bons résultats en
diminuant le rayon (0,8 par exemple).
Personnellement je teste d'abord un gauss à 0.9 et tout le reste à 0,
sauf le noise à 0.01. Puis, si ce n'est pas satisfaisant, je joue sur les
trois autres paramètres pour atténuer les artefacts.
Sinon, j'ai peu de différences entre une matrice 3x3 et 10x10.
Pourtant dans la théorie l'algo est sensé en dépendre assez notablement.
As-tu aussi constaté cela ?
En espérant que çà aide...
Bien sûr !
--
Christian Tsotras - ICQ:37288308
http://www.photo.net/shared/community-member?user_id)5376
On Fri, 16 Apr 2004 22:30:25 +0200, Jean-Louis Hamel wrote:
Sous Windows, il plantait effectivement en fin de calcul lorsque l'une des dimensions de l'image n'était pas multiple de 64
Sous Linux, il plante lorsque la boîte de dialogue lance le traitement de l'image complète. J'ai fait des tests avec des sélections, et effectivement, le plantage se produit lorsque la sélection est presque aussi grande que l'image, moins quelques dizaines de pixels.
Si le problème ne se produit pas sur ta Mandrake, peut-être est-ce parce que tu y as installé la version précompilée "Mandrake". Mon PC est sur Redhat 9, et j'ai compilé Gimp **1.2.5** depuis les sources.
Je suspecte que ce problème (c'est un débordement de tampon mémoire) pourrait également provoquer un plantage sous Linux. [...]
Voici la modif à faire: dans tilebuf.c il faut insérer après la ligne 232 l'instruction:
Merci pour ces détails, je vais tester.
pour imprimer je me demande encore si c'est mieux qu'un "sharpen" classique ... A mon avis, c'est justement en impression que je le trouve supérieur.
Pour le Web, avec de petites images, on obtient de bons résultats en diminuant le rayon (0,8 par exemple).
Personnellement je teste d'abord un gauss à 0.9 et tout le reste à 0, sauf le noise à 0.01. Puis, si ce n'est pas satisfaisant, je joue sur les trois autres paramètres pour atténuer les artefacts.
Sinon, j'ai peu de différences entre une matrice 3x3 et 10x10. Pourtant dans la théorie l'algo est sensé en dépendre assez notablement.
As-tu aussi constaté cela ?
En espérant que çà aide...
Bien sûr !
-- Christian Tsotras - ICQ:37288308 http://www.photo.net/shared/community-member?user_id)5376
Jean-Louis Hamel
On Fri, 16 Apr 2004 22:30:25 +0200, Jean-Louis Hamel wrote:
Sous Windows, il plantait effectivement en fin de calcul lorsque l'une des dimensions de l'image n'était pas multiple de 64
Sous Linux, il plante lorsque la boîte de dialogue lance le traitement de l'image complète. J'ai fait des tests avec des sélections, et effectivement, le plantage se produit lorsque la sélection est presque aussi grande que l'image, moins quelques dizaines de pixels.
Si le problème ne se produit pas sur ta Mandrake, peut-être est-ce parce que tu y as installé la version précompilée "Mandrake". Mon PC est sur Redhat 9, et j'ai compilé Gimp **1.2.5** depuis les sources.
Mon GIMP vient de mandrake, mais j'ai compilé le plug-in. Je pense que çà ne plante pas par un hasard heureux: un débordement de mémoire peut se produire à un endroit où çà ne gène pas. En fait, d'après ce que j'ai cru voir, ce débordement se produit lors d'un calcul voisin du bord inférieur de l'image. Ma correction effectue un test plus précis de la borne inférieure à ne pas dépasser. Finalement, je vais la faire aussi sous Linux.
Personnellement je teste d'abord un gauss à 0.9 et tout le reste à 0, sauf le noise à 0.01. Puis, si ce n'est pas satisfaisant, je joue sur les trois autres paramètres pour atténuer les artefacts.
J'ai tendance à laisser toujours gauss à 0 (trop d'artefact sinon), comme le conseille l'auteur et à augmenter la correlation si l'effet est trop fort, en laissant le noise à 0.1.
Sinon, j'ai peu de différences entre une matrice 3x3 et 10x10. Pourtant dans la théorie l'algo est sensé en dépendre assez notablement.
As-tu aussi constaté cela ?
J'ai fait de tests sur des images comportant beaucoup de détails fins et irréguliers comme des branchages sur fond de ciel bleu. C'est nettement meilleur (et plus lent) avec 10x10 qu'avec 5x5. Celà doit être moins sensible sur des objets avec des contours géométriques par exemple.
-- JLH
On Fri, 16 Apr 2004 22:30:25 +0200, Jean-Louis Hamel wrote:
Sous Windows, il plantait effectivement en fin de calcul lorsque l'une
des dimensions de l'image n'était pas multiple de 64
Sous Linux, il plante lorsque la boîte de dialogue lance le traitement de
l'image complète. J'ai fait des tests avec des sélections, et
effectivement, le plantage se produit lorsque la sélection est presque
aussi grande que l'image, moins quelques dizaines de pixels.
Si le problème ne se produit pas sur ta Mandrake, peut-être est-ce parce
que tu y as installé la version précompilée "Mandrake". Mon PC est sur
Redhat 9, et j'ai compilé Gimp **1.2.5** depuis les sources.
Mon GIMP vient de mandrake, mais j'ai compilé le plug-in.
Je pense que çà ne plante pas par un hasard heureux: un débordement de
mémoire peut se produire à un endroit où çà ne gène pas. En fait,
d'après ce que j'ai cru voir, ce débordement se produit lors d'un calcul
voisin du bord inférieur de l'image. Ma correction effectue un test plus
précis de la borne inférieure à ne pas dépasser. Finalement, je vais la
faire aussi sous Linux.
Personnellement je teste d'abord un gauss à 0.9 et tout le reste à 0,
sauf le noise à 0.01. Puis, si ce n'est pas satisfaisant, je joue sur les
trois autres paramètres pour atténuer les artefacts.
J'ai tendance à laisser toujours gauss à 0 (trop d'artefact sinon),
comme le conseille l'auteur et à augmenter la correlation si l'effet est
trop fort, en laissant le noise à 0.1.
Sinon, j'ai peu de différences entre une matrice 3x3 et 10x10.
Pourtant dans la théorie l'algo est sensé en dépendre assez notablement.
As-tu aussi constaté cela ?
J'ai fait de tests sur des images comportant beaucoup de détails fins et
irréguliers comme des branchages sur fond de ciel bleu. C'est nettement
meilleur (et plus lent) avec 10x10 qu'avec 5x5. Celà doit être moins
sensible sur des objets avec des contours géométriques par exemple.
On Fri, 16 Apr 2004 22:30:25 +0200, Jean-Louis Hamel wrote:
Sous Windows, il plantait effectivement en fin de calcul lorsque l'une des dimensions de l'image n'était pas multiple de 64
Sous Linux, il plante lorsque la boîte de dialogue lance le traitement de l'image complète. J'ai fait des tests avec des sélections, et effectivement, le plantage se produit lorsque la sélection est presque aussi grande que l'image, moins quelques dizaines de pixels.
Si le problème ne se produit pas sur ta Mandrake, peut-être est-ce parce que tu y as installé la version précompilée "Mandrake". Mon PC est sur Redhat 9, et j'ai compilé Gimp **1.2.5** depuis les sources.
Mon GIMP vient de mandrake, mais j'ai compilé le plug-in. Je pense que çà ne plante pas par un hasard heureux: un débordement de mémoire peut se produire à un endroit où çà ne gène pas. En fait, d'après ce que j'ai cru voir, ce débordement se produit lors d'un calcul voisin du bord inférieur de l'image. Ma correction effectue un test plus précis de la borne inférieure à ne pas dépasser. Finalement, je vais la faire aussi sous Linux.
Personnellement je teste d'abord un gauss à 0.9 et tout le reste à 0, sauf le noise à 0.01. Puis, si ce n'est pas satisfaisant, je joue sur les trois autres paramètres pour atténuer les artefacts.
J'ai tendance à laisser toujours gauss à 0 (trop d'artefact sinon), comme le conseille l'auteur et à augmenter la correlation si l'effet est trop fort, en laissant le noise à 0.1.
Sinon, j'ai peu de différences entre une matrice 3x3 et 10x10. Pourtant dans la théorie l'algo est sensé en dépendre assez notablement.
As-tu aussi constaté cela ?
J'ai fait de tests sur des images comportant beaucoup de détails fins et irréguliers comme des branchages sur fond de ciel bleu. C'est nettement meilleur (et plus lent) avec 10x10 qu'avec 5x5. Celà doit être moins sensible sur des objets avec des contours géométriques par exemple.
