J'imagine que gegl ne fait pas d'optimisation, il n'est pas capable d'éviter la création d'un buffer lorsque l'on passe d'un noeud d'un graph à un autre ?
Je ne suis pas le mieux calé pour parler de GEGL. Aucun de mes patchs là-bas ne sont algorithmiques. J'y touche plus dans le cadre de problèmes rencontrés dans GIMP que pour GEGL même. Donc ma première réponse, c'est que je ne sais pas s'il fait la moindre optimisation pour réduire des opérations.
Mais est-ce qu'il pourra le faire à terme ?
S'il ne fait pas déjà, je ne vois rien qui empêche de le faire à l'avenir. Ensuite il y a des cas plus simples que d'autres. Par exemple, il y a toute une série d'opérations qui sont matricielles (les transformations mathématiques: rotation, translation, réflexion, changement d'échelle...), et bon ça la multiplication de matrice, c'est pas compliqué! Si on a plusieurs opérations matricielles de ce style qui se suivent, on devrait être capable très simplement de les combiner en une seule de façon transparente (tout en gardant une visualisation multi-nœuds).
D'ailleurs c'est peut-être déjà fait, aucune idée!
Pour d'autres types d'opérations, j'imagine que ça dépend. Beaucoup de choses simples à faire pour un humain ne le sont pas pour un ordi (et vice-versa). Donc à part programmer des cas particuliers partout (possible aussi, et cela reste intéressant si certains cas particuliers sont des optimisations connus pour faire gagner énormément et difficilement automatisables autrement), ce qu'il faut, c'est réorganiser le code pour créer des schémas.
Par exemple, une opération qui traite chaque pixel l'un après l'autre, ce dont tu parles, si c'est entièrement codé comme une boucle de programmation, c'est dur à réduire (car un programme ne "comprend" pas son propre code!). Par contre, on devrait être capable de faire une sous-classe d'opération pour les opérations "pareil sur tous les pixels" où — au lieu de faire des boucles sur les pixels — on donne juste l'opération mathématique à appliquer sur le contenu d'un pixel. À ce moment là, le programme sera capable d'enchaîner les opérations dans la même boucle, ce qui est déjà une bonne optimisation.
Ensuite il faut faire attention à ne pas introduire d'erreurs. Dans notre cas précis, cela fonctionne si les seules données extérieures sont indépendantes de l'image. Si par exemple, la modification d'un pixel utilise les données d'autres pixels, alors ce n'est plus possible (du moins plus aussi facile). En effet, la seconde opération utiliserait le pixel après modification par la première opération. Or si on exécute l'optimisation "2 opérations en une", elle n'aurait accès qu'au pixel avant modification par la première opération! On introduirait donc une erreur puisque le résultat serait différent.
Enfin voilà, tout est possible, mais faut bien y réfléchir et trouver l'architecture idéale.
Et dans tous les cas, il est conseillé de faire un programme qui marche bien avant de l'optimiser. Règle de base du bon programmeur. :-)
Je pause cette question, car pour avoir utiliser darktable, qui ne fait pas de destructif non plus, il arrive vite à manger toute la mémoire, avec seulement quelques opérations.
Ensuite y a pas de miracle. Le non-destructif a de gros avantages, mais ce n'est pas magique. Ça a son prix. La qualité a toujours son prix, c'est la raison pour laquelle dans beaucoup de workflow, il ne sert à rien d'en faire. C'est comme utiliser du jpg pour le web. Utiliser du png est théoriquement bien meilleur, mais dans 99% des cas, si l'usage est "web", alors on va exporter en jpg et de toutes façons personne (pas même soi-même) ne verra la différence. Par contre, quand on exporte pour travailler ailleurs, ou intégrer dans une vidéo, c'est du PNG.
Il faut savoir choisir les pratiques en fonction des besoins.
De manière générale travailler sur des données médias (son, et encore plus image), ça prend une place de dingue.
Pour ZeMarmot, nos ressources pour le teaser de 1 min font plusieurs GO de données! Notamment on travaille en HD avec des fichiers XCF qui peuvent dépasser 100 MB. Et encore on a des retours de gens qui travaillent dans des secteurs où leurs fichiers XCF font plusieurs GB! (ceux qui scannent des images à extrêmement haute résolution par exemple, ou des secteurs médicaux, scientifiques, etc.) Donc oui bien sûr, dans leur cas, rien qu'ouvrir l'image peut prendre toute la mémoire sur un ordi de base du supermarché.
Bon ces tailles de fous ne sont pas la majorité. Mais plusieurs centaines de MB par contre, c'est courant. Donc de nos jours, si tu travailles des images (photos, dessins...), avoir 8GB de RAM, c'est pas grand chose. Être à 16 ou même 32 GB, c'est pas du luxe. C'est inhérent même aux qualités et résolutions qu'on atteint maintenant avec l'imagerie (même amateur).
En conclusion: oui on peut probablement optimiser, et on le fera sûrement (développeurs recherchés! Si tu développes et souhaites ajouter le type d'optimisation dont on a parlé ici, tu es le bienvenu!). Mais faut pas non plus croire au miracle. Si tu charges des images de dizaines de Mégas par défaut (cas des images DSLR de nos jours), et que tu fais des dizaines d'opérations dessus, oui ça monte vite.
Faire du destructif est une possibilité et peut très bien être un choix valide. Tu perds en flexibilité et potentiellement en qualité du résultat final par contre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 7.
Je ne suis pas le mieux calé pour parler de GEGL. Aucun de mes patchs là-bas ne sont algorithmiques. J'y touche plus dans le cadre de problèmes rencontrés dans GIMP que pour GEGL même. Donc ma première réponse, c'est que je ne sais pas s'il fait la moindre optimisation pour réduire des opérations.
S'il ne fait pas déjà, je ne vois rien qui empêche de le faire à l'avenir. Ensuite il y a des cas plus simples que d'autres. Par exemple, il y a toute une série d'opérations qui sont matricielles (les transformations mathématiques: rotation, translation, réflexion, changement d'échelle...), et bon ça la multiplication de matrice, c'est pas compliqué! Si on a plusieurs opérations matricielles de ce style qui se suivent, on devrait être capable très simplement de les combiner en une seule de façon transparente (tout en gardant une visualisation multi-nœuds).
D'ailleurs c'est peut-être déjà fait, aucune idée!
Pour d'autres types d'opérations, j'imagine que ça dépend. Beaucoup de choses simples à faire pour un humain ne le sont pas pour un ordi (et vice-versa). Donc à part programmer des cas particuliers partout (possible aussi, et cela reste intéressant si certains cas particuliers sont des optimisations connus pour faire gagner énormément et difficilement automatisables autrement), ce qu'il faut, c'est réorganiser le code pour créer des schémas.
Par exemple, une opération qui traite chaque pixel l'un après l'autre, ce dont tu parles, si c'est entièrement codé comme une boucle de programmation, c'est dur à réduire (car un programme ne "comprend" pas son propre code!). Par contre, on devrait être capable de faire une sous-classe d'opération pour les opérations "pareil sur tous les pixels" où — au lieu de faire des boucles sur les pixels — on donne juste l'opération mathématique à appliquer sur le contenu d'un pixel. À ce moment là, le programme sera capable d'enchaîner les opérations dans la même boucle, ce qui est déjà une bonne optimisation.
Ensuite il faut faire attention à ne pas introduire d'erreurs. Dans notre cas précis, cela fonctionne si les seules données extérieures sont indépendantes de l'image. Si par exemple, la modification d'un pixel utilise les données d'autres pixels, alors ce n'est plus possible (du moins plus aussi facile). En effet, la seconde opération utiliserait le pixel après modification par la première opération. Or si on exécute l'optimisation "2 opérations en une", elle n'aurait accès qu'au pixel avant modification par la première opération! On introduirait donc une erreur puisque le résultat serait différent.
Enfin voilà, tout est possible, mais faut bien y réfléchir et trouver l'architecture idéale.
Et dans tous les cas, il est conseillé de faire un programme qui marche bien avant de l'optimiser. Règle de base du bon programmeur. :-)
Ensuite y a pas de miracle. Le non-destructif a de gros avantages, mais ce n'est pas magique. Ça a son prix. La qualité a toujours son prix, c'est la raison pour laquelle dans beaucoup de workflow, il ne sert à rien d'en faire. C'est comme utiliser du jpg pour le web. Utiliser du png est théoriquement bien meilleur, mais dans 99% des cas, si l'usage est "web", alors on va exporter en jpg et de toutes façons personne (pas même soi-même) ne verra la différence. Par contre, quand on exporte pour travailler ailleurs, ou intégrer dans une vidéo, c'est du PNG.
Il faut savoir choisir les pratiques en fonction des besoins.
De manière générale travailler sur des données médias (son, et encore plus image), ça prend une place de dingue.
Pour ZeMarmot, nos ressources pour le teaser de 1 min font plusieurs GO de données! Notamment on travaille en HD avec des fichiers XCF qui peuvent dépasser 100 MB. Et encore on a des retours de gens qui travaillent dans des secteurs où leurs fichiers XCF font plusieurs GB! (ceux qui scannent des images à extrêmement haute résolution par exemple, ou des secteurs médicaux, scientifiques, etc.) Donc oui bien sûr, dans leur cas, rien qu'ouvrir l'image peut prendre toute la mémoire sur un ordi de base du supermarché.
Bon ces tailles de fous ne sont pas la majorité. Mais plusieurs centaines de MB par contre, c'est courant. Donc de nos jours, si tu travailles des images (photos, dessins...), avoir 8GB de RAM, c'est pas grand chose. Être à 16 ou même 32 GB, c'est pas du luxe. C'est inhérent même aux qualités et résolutions qu'on atteint maintenant avec l'imagerie (même amateur).
En conclusion: oui on peut probablement optimiser, et on le fera sûrement (développeurs recherchés! Si tu développes et souhaites ajouter le type d'optimisation dont on a parlé ici, tu es le bienvenu!). Mais faut pas non plus croire au miracle. Si tu charges des images de dizaines de Mégas par défaut (cas des images DSLR de nos jours), et que tu fais des dizaines d'opérations dessus, oui ça monte vite.
Faire du destructif est une possibilité et peut très bien être un choix valide. Tu perds en flexibilité et potentiellement en qualité du résultat final par contre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]