[GSOC] Outil de transformation par cage

[Bat'O]

Bonjour à tous,

Je suis l'étudiant qui va réaliser un des Google summer of code pour Gimp. Mon projet est de réaliser un nouvel outil de transformation par l'intermédiaire d'une cage.

Cet outil devrait ressembler plus ou moins à ceci: http://www.cs.technion.ac.il/~weber/Pub ... coords.mov

Voilà, tout ça pour dire deux choses:

- J'ai ouvert un blog où je parlerai des évolutions de mon projet. Il est ici: http://pellelatarte.fr
Vous y trouverez également plus de détails sur ce que j'ai prévu de faire.

- Je suis très intéressé par vos avis. Cet outil, c'est vous qui allez l'utiliser (j'espère en tout cas). Si vous pensez qu'un truc ne va pas, dites le moi ! Soit ici, soit sur le blog.

Voilà, j'arrête de vous saouler

Michael

[Raymond]

Merci de nous signalé ton blog. Bonne chance pour ton projet GSOC !

Quelques commentaires puisque tu nous en demandes.

L'exemple du lézard semble parfait sur un fond uni mais quid d'un lézard sur un fond non uni constitué par exemple de pierres ? Est-ce que le fond va suivre tout ou partiellement la déformation, ou bien sera-t-il complètement découpé par la cage ? Je pense qu'il faudra proposer que le fond suive la déformation avec un rayon d'action paramétrable, ceci pour éviter à détourer systématiquement le lézard.

Plutot qu'une cage constituée d'un polygone assez difficile à manipuler, je verrai bien un squelette central (par exemple fait avec l'outil Chemin) et un rayon d'action de la déformation. Le squelette serait intuitivement facile à construire en fonction de la déformation à obtenir. Sa manipulation serait plus simple que la cage.

L'outil de transformation par cage étant manifestement ludique il ne faudrait pas le gâcher avec un aperçu trop lent. Des aperçus partiels rapides + un bouton appliquer pour le calcul final sont déjà utilisés pour d'autres transformations.

[EminoMeneko]

C'est monstrueux comme outil !
L'intérêt pour l'animation est indéniable même si en effet on peut se demander comment ça gère les pixels autour sur un fond non uni. J'ai quand même pu observer qu'on utilise plusieurs types de coordonnées et qu'en fonction de ça les pixels autour sont "absorbés" ou pas.
Personnellement l'outil dont j'ai envie en ce moment c'est un pinceau qui déforme les pixels comme dans le filtre Déformations interactives ou iWarp chez nos amis anglophones, mais je vois qu'on peut fait à peu près la même chose avec ça. Disons que c'est une autre manière de travailler.
Sinon tu as bien du courage.
J'ai déjà du mal à mettre en place des sockets en Java ou a coder un puzzle en Delphi...

Bon courage. (Bon UML, bonne doc et bon dev)

[Bat'O]

Haaa, enfin du feedback

Les Green Coordinates, c'est à dire la partie mathématique qui est derrière la déformation ne sont définis qu'a l'intérieur de la cage. Ça implique que les pixels seront effectivement découpé net par les bords de la cage. J'ai cependant commencé à discuter avec un des dev de Gimp, Simon Budig, qui est très calé en math pour trouver une solution à ça. Mais ça ne fera pas partie de mon summer of code, c'est déjà bien assez compliqué comme ça ! :p
A voir pour une amélioration ultérieure donc.

Pour ce qui est de la façon de manipuler la cage, c'est effectivement un point important. Une mauvaise interface peut rapidement transformer le bidule en un truc complètement inutile. Ca sera la deuxième partie de mon soc, en collaboration avec Peter Siking, alias Guiguru.
Si je peux faire en sorte de manipuler un ensemble de poignée de la cage en fonction de la distance par rapport au curseur, (plus ou moins comme dans la vidéo donc), je ne vois pas trop l'intérêt de mettre un squelette. A priori, ça devrait être aussi efficace, sans s'embêter à créer un squelette. Mais peut être que je me plante ?

L'aperçu sera normalement au programme également.

Un autre truc auquel je pense actuellement, c'est la création de la cage automatiquement, d'après la forme de la sélection. Mais ça sera pas tout de suite non plus.

[EminoMeneko]

Fais ce que tu peux du mieux que tu peux.
Après pas la peine de te mettre trop la pression. On te demandera pas d'être capable de dév un photoshop en 2 jours.
Les grands projets aussi commencent petit. C'est un peu comme un oignon mais au lieu d'enlever les pelures on en rajoute petit à petit.
J'ai hâte de voir ce que ça donne même si ça devait pas être super génial pour cette première release. En fait le plus bête ce serait d'en rester à l'état du GSOC et puis plus rien.
Bonne chance donc pour ton projet. Moi en ce moment je galère à essayer de faire marcher des sockets en Java.
D'ailleurs ça sera dev en quel langage ?

[Bat'O]

Je suis pas sûr que tu es bien compris. Mon projet est un nouvel outil pour Gimp, pas un nouveau logiciel.

Gimp est écrit en C (4,5 millions de ligne), et utilise beaucoup les gObject (une sorte d'implémentation des concepts orienté objet en C).
Je vais également coder quelques trucs dans les libraires Babl et Gegl, en C également.

Sinon, merci pour les encouragements

[olivs]

Bat'O,

je te souhaites une bonne réussite dans ce projet. Si tu as besoin de ressources spécifiques sur Linuxgraphic pour t'aider à avancer, contacte-moi par MP et nous nous ferons un plaisir de voir ce qu'il est possible de mettre en place pour t'épauler. Tu as un blog, c'est la base mais c'est déjà super pour tous les afficionados de Gimp.

Cordialement,

Olivier

[EminoMeneko]

Si si, j'avais parfaitement compris. C'est plutôt toi qui m'a mal compris on dirait.
J'ai pas parlé de dev un Photoshop en 2 jours en pensant que tu ferais une nouvelle appli. mais même des applis comme Photoshop on connus un début avec peu de fonctionnalités comparé à ce que c'est devenu.
Bon je laisse le pro du C suer avec son outil. et moi je vais suer à essayer de faire marcher cette satanée socket (j'y suis presque)... xD
En tout cas tu l'auras compris à part des encouragements, je ne crois pourvoir t'être très utile.

[stilobique]

C'est un outil vraiment intéressant ! J'ai hâte devoir l'aboutissement du projet, bonne chance.