Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Modules externes ?
#1
Bonjour, je ne sais pas très bien où poster cette réflexion au sujet de "modules externes" qui me trotte dans la tête depuis quelques temps.

Dans bibble (qui n'était pas Open Source) plus tard devenu AfterShot Pro de Corel (toujours pas Open Source), il y avait/a la possibilité d'intégrer des modules externes de développeurs tiers, certains vraiment très pratiques, pour pas dire indispensables, et pour beaucoup sous licence libre.
Il y en avait même "à deux vitesses", une version FLOSS gratuite, une version plus étoffée et payante (je n'ai pas souvenir qu'elles aient été chères).

On peut aussi penser à G'MIC dans GIMP, dont on apprécie rapidement leur côté pratique et les extensions de possibilités que ça procure.

Bon, pour être franc depuis que j'ai vu le travail d'@aurelienpierre, et que je me dis que ça sera pas avant un an au mieux pour le voir intégré dans DT (à part compiler la version intermédiaire...), je me dis que si par exemple des versions α/ß/RC ou même release pouvaient être rajoutées par un tel mécanisme de module externe... Cool
dt stable / Ubuntu 22.04
Répondre
#2
Je me souviens très bien de ces modules dans Bibble. J'en avais tout une collection dont lindispensable Noise Ninja (disparu sous corel :-( ). Après, je ne sais pas si DT a été prévu pour fonctionner de la même manière...
"Donne un poisson à un homme, tu le nourris pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours."
Pop Os! 64 Bits Gnome 3.32 Sony A7 et quelques vieux cailloux...
Répondre
#3
Intégrer un module au milieu (ou au début, ou à la fin) du pipeline n'est probablement pas une mince affaire. L'organisation des modules dans le pipeline est étudiée avec beaucoup de soin pour assurer une qualité optimale des images. Faudrait déterminer l'emplacement dans le pipeline en fonction du traitement fourni par le module..., établir une API L*a*b* ou RGB..., et sûrement plein d'autres contraintes...

C'est d'ailleurs pour ça que Lua n'est pas disponible en chambre noire.
Mes photos : jpverrue.fr
Répondre
#4
Oui @jpverrue, il faut sans doute que ça soit "désigné" pour, dans le logiciel. Sans doute le cas depuis le début sur bibble, que je n'ai connu qu'à la version 4 (avec les modules externes). Sinon il y a nécessairement une spéc d'interfaçage (voire plus) pour les développeurs de modules externes.

@Carafife, pareil j'avais ma collec' de modules dont Noise Ninja (licencié) perdu au passage d'ASP... Angry
dt stable / Ubuntu 22.04
Répondre
#5
(02-12-17, 19:10)manu a écrit : @Carafife, pareil j'avais ma collec' de modules dont Noise Ninja (licencié) perdu au passage d'ASP... Angry

la perte de Noise Ninja suite au passage à Corel est la raison première pour laquelle j'ai cherché une alternative et suis passé à Darktable. C'est probablement la seule bonne chose qui est arrivé suite au rachat par Corel Wink
Luc Viatour Photographe 
Website
Répondre
#6
Ce que tu recherches ressemble fort à http://www.darktable.org/2015/04/introdu...app-store/ . Le fait que ceci ait été proposé comme poisson d'avril est un bon indice du fait que ça a peu de chance d'arriver.

Un gros problème avec la notion de « module externe » pour un outil comme darktable, c'est l'aspect « non-destructif » de l'outil. Si je traite aujourd'hui une image avec un plugin GIMP et que ce plugin disparaît demain, je pourrais toujours ouvrir mon image sans utiliser le plugin. Avec darktable, pour pouvoir ré-ouvrir une image plus tard, il faut absolument que tous les modules utilisés sur l'image soient encore présents sur la version de darktable utilisée pour ouvrir.

En d'autre termes, si on pouvait utiliser des modules externes, on perdrait toutes les images l'utilisant le jour où le module externe disparaîtrait. Je préfère de loin l'approche où les développeurs sont forcés d'intégrer leurs modules dans la branche officielle pour qu'ils soient utilisables !
Répondre
#7
(03-12-17, 14:46)mmoy a écrit : Ce que tu recherches ressemble fort à http://www.darktable.org/2015/04/introdu...app-store/ . Le fait que ceci ait été proposé comme poisson d'avril est un bon indice du fait que ça a peu de chance d'arriver.

Un gros problème avec la notion de « module externe » pour un outil comme darktable, c'est l'aspect « non-destructif » de l'outil. Si je traite aujourd'hui une image avec un plugin GIMP et que ce plugin disparaît demain, je pourrais toujours ouvrir mon image sans utiliser le plugin. Avec darktable, pour pouvoir ré-ouvrir une image plus tard, il faut absolument que tous les modules utilisés sur l'image soient encore présents sur la version de darktable utilisée pour ouvrir.

En d'autre termes, si on pouvait utiliser des modules externes, on perdrait toutes les images l'utilisant le jour où le module externe disparaîtrait. Je préfère de loin l'approche où les développeurs sont forcés d'intégrer leurs modules dans la branche officielle pour qu'ils soient utilisables !

Oui c'était un poisson d'avril, les quelques commentaires montrent tout de même un franc intérêt par certains...

Si le codeur d'un module externe laisse tomber l'affaire, le module n'évoluera certes plus mais il continuera de fonctionner tant que DT ne change pas d'API ou que sais-je.
Par ailleurs, s'il est sous licence libre, il pourra être récupéré par la communauté ou d'autres développeurs. Et il n'est pas exclu que des modules externes intègrent à terme le core...
dt stable / Ubuntu 22.04
Répondre
#8
C'est tout à fait possible de faire cela. Tous les modules sont des bibliothèques dynamiques dans lib/darktable/plugins/

Il suffit au développeur de fournir un .so à copier. Ou encore mieux un fork de darktable avec le plug-in ajouté (avec les sources) pour que chacun puisse recompiler Smile
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)