Petite question à ce sujet... L'édition non destructrice est intéressante, mais il me semble qu'elle se limite quand même à des filtres de traitement d'images "basiques", rapides à calculer. De même pour la fonctionnalité "preview on canvas" qui est poussée en avant pour les prochaines releases avec GEGL.
On imagine mal en effet devoir attendre 15 minutes (au hasard) le recalcul d'un rendu après avoir changé un paramètre d'un des filtres (parce que le graphe comprend un filtre très long à calculer, qui a été appliqué à la fin).
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Avez vous prévu quelque chose de spécial dans ce cas ?
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler... Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Si non, cela veut-il dire que les opérateurs GEGL seront de toute façon limités à des traitements basiques, si on veut les rendre utilisables en pratique ?
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler... Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]