Pour la compatibilité des traitements, je pense que c’est une question qui dépend beaucoup d’une personne à l’autre. Personnellement, je préfère privilégier mes traitements futurs, au détriment de la compatibilité avec les anciens : si le changement peut me faire gagner en temps de traitement et en qualité de traitement, je trouve ça aussi bien de le refaire.
Aurélien avait souligné un point important pour la compatibilité, le fait qu’il y a actuellement des modules après le profil de couleur de sortie, et que du coup un simple changement d’écran peut entraîner des différences sur le traitement, si j’ai bien compris (@Aurélien je te laisse me corriger si je dis des bêtises).
Autrement dit, la compatibilité n’est pas actuellement assurée pour certains modules…
De mon point de vue, il faut faire les changements qui sont nécessaire pour avoir une meilleure qualité de traitement et résoudre ces problèmes, et la compatibilité doit être assurée pour la table lumineuse.
Pour la chambre noire, une rupture de compatibilité ne me dérangerai pas si elle est ponctuelle et unique (je ne souhaite pas des ruptures de compatibilité régulières)
Mon grain de sel dans ce débat fort intéressant.
Je suis passé de CNX2 à CNX-D sans pouvoir récupérer mes traitements, ce dernier récupérait les traitements pour les lire mais pas les continuer.
Je suis en suite passé de CNX-D à daktable sous Windows d’abord pyis sous linux et la encore je nai pas pu récupérer les traitements.
Par contre je peux comparer ancien et nouveau à partir du jpg. En fait un fork peut être comparé à un changement de logiciel de traitement. On l’accepte. …ou pas.
Dans l’état actuel je préférais tout de même avoir le choix au niveau des préférences entre actu et ng. @aurelienpierre compte tenu de ce qui a été dit par plus compétant que moi. …tu es maître de la décision. Ayant appris à compiler avec docker, si tu prends la decision d’une branche dev en parallèle je pourrais au moins suivre voire tester.
Je suis avec un grand intérêt ce fil car je suis très sensible aux arguments d’Aurélien sur la cohérence du pipeline de traitement car je comprend mieux pourquoi certains effets de bord ne me paraissaient pas logique dans mes traitements, déjà merci pour avoir éclairer ce point !!
Pour cette facette là je suis entièrement d’accord qu’il faudrait réorganiser le pipeline interne (déjà qu’il soit plus visible pour ne pas faire de conneries ce serait bien !! ), ensuite forker « agressivement » se serait plutôt dommage car ça risque de casser la dynamique de la communauté DT. Problème assez insoluble.
La petite phrase d’Andy juste 2 message au-dessus de moi présente la solution d’un « concurrent » qui a été face au même problème et cela me parait très intéressant. Reste à voir si c’est faisable dans la pratique au niveau code !
Pour voir le pipelime, c’est possible depuis longtemps, ne semble depuis la première version :
Il suffit de cliquer sur le premier onglet en forme de bouton « On/Off ». Tu vois exactement le déroulement des modules dans le pipeline du bas vers le haut. Tu vois aussi des modules qui sont effectués d’office par darktable : ceux qui m’ont pas de bouton « On/Off » devant. Et tu vois que c’est différent que dans l’historique.
Je recommente ici comme ma réflexion évolue.
L’option proposée par Pascal me parait être le bon compromis, pour éviter de diviser les ressources (au dela des devs, il y a des traducteurs, des testeurs, des personnes qui font les packages des différentes plateformes, le site web, les gens qui font des tutos, etc). darktable serait par défaut en mode next-gen, et pourrait revenir en mode ancien lorsque nécessaire par compatibilité. @aurelienpierre, penses tu qu’il y a des modifs nécessaires qui ne pourraient pas se faire dans cette option ?
Le fait de pouvoir changer l’ordre des modules, qui a été évoqué, me parait aussi intéressant (par exemple pour inverser l’ordre de la reduction de bruit bilatéral et de la reduction de bruit de profil).
il est tout a fait possible de faire que l’ordre des modules soit changé (un peu comme ce que j’ai fait pour la position des modules), c’est une modification assez simple mais qui demande de toucher à tous les modules.
pour les routines cores je pense que tout est possible aussi, mais je n’ai pas vraiment de solution car je ne sais pas tout ce qu’il y a dans la tête d’Aurélien pour la version next-gen.
En tout cas vous pouvez compter sur moi pour avancer dans cette direction.
Merci Pascal d’avoir donné des infos sur les modifications qui peuvent être faites simplement et ta position concernant une mise à niveau un peu plus en profondeur.
Merci beaucoup Pascal, et merci pour ces explications.
Pour l’ordre des modules, ça te parait faisable de pouvoir avoir deux instances d’un même module séparées par un autre ?
En parlant de « next-gen », a-t-il été discuté au cours des années de la mise en place d’une prise en main lors du « premier lancement »: hors de propos, oui mais comment, oui mais faut coder-maintenir tout cela?
Par exemple, les premiers Polarr Photo Editor proposaient des pas à pas directement dans le logiciel (de mémoire 4 images pour 4 thématiques de traitement). J’avais adoré cette prise en main qui, l’air de rien, donne des repères et confiance.
Pour dt, des tutos sont dédiés pour nombre de modules et l’aide est désormais intégrée; je pense plus à la ou les « philosophies » de développement?
Cela peut-être aussi une vidéo courte qui donne des clefs sur l’interface suivi d’une approche de dvpt avec dt?
J’apporte mon grain de sel.
Le fork c’est un travail de titan car outre le fait de « corriger » les défauts, il faut apporter de nouvelles fonctionnalités, refaire une base d’utilisateur, de testeur, packagueur ( pour les 3 OS), sans oublier les traducteurs, le support que cela engendre vu la cassure que cela va occasionner. Ce n’est pas une décision á prendre à la légère.
Regardez le cas openwrt qui a été forker et depuis 1 ans les deux projets fusionne pour prendre le meilleur des deux car les deux deux projets n’avancaient plus vraiment.
Je suis a 100% avec tes idées @aurelien, car je suis certain que les techniques on grandement évoluer depuis la première version et qu’un bon nettoyage est nécessaire pour optimiser tout cela, selon les « nouvelles normes ».
Regardez Microsoft qui a abandonné certaine version de Windows… pour en faire de meilleur ( très subjectif) ou encore apple qui n’a pas hésité a cassé complètement son os quitte a foutre un sacré bordel avec sa première version de Mac os x. Ces boîtes peuvent se le permettre car l’argent que cela génère leur permet de rebondir… Mais quand même certain pari ont été risqué pour eux.
J’en vois passer très régulièrement des changements de stratégie sur les soft médicaux que nous utilisons ( je bosse dans l’informatique médical) pour voir certain projets remis en cause au bout de 3/4 ans et de fait voir les applications changer malgres un moteur qui n’évolue guère.
Je suis pour prendre un peux de temps pour voir ce qui peux être amener comme changement dans la version actuelle et avoir un -gen en parallèle via une option a activer. C’est sur que le boulot va être monstrueux mais cela ne fera qu’apporter des arguments positif au changement que tu souhaites faire. Et cela permettra d’infléchir les anciens [emoji39]
Ne perds pas courage n’y espoir, la communauté est derrière toi.
Je comptais faire un tuto video de prise en main (en français et en anglais) de la chambre noire à l’occasion de la sortie de la version 2.6 pour montrer vers quels modules s’orienter. L’idée est de montrer rapidement comment faire les choses de base (modifier les couleurs, faire du noir et blanc, modeler les contrastes globaux et locaux, débruiter,. …), en montrant un minimum de modules (typiquement, le noir et blanc avec zone de couleurs, et pas avec monochrome ou mixeur de canaux, le débruitage avec uniquement la réduction de bruit de profil, etc), et introduisant très rapidement les masques aussi, et surtout en dirigeant vers les tutos de Carafife.
Je suis pas sûr que la vidéo sera très courte par contre haha
Il semble que la bataille soit lancée Avec ce PR on va dessiner les lignes clairement entre les conservateurs et les autres. Les discussions sérieuses vont commencer!
Tout cela sera pour début 2019 de toutes façons, mais je viendrais ici faire le rappel pour apporter plus de votes dans notre direction
Il semble que la bataille soit lancée Avec ce PR on va dessiner les lignes clairement entre les conservateurs et les autres. Les discussions sérieuses vont commencer!
Tout cela sera pour début 2019 de toutes façons, mais je viendrais ici faire le rappel pour apporter plus de votes dans notre direction
[/quote]Pour ma culture et certainement d’autres, qui est edgardoh ? Désolé pour mon ignorance.
Pour ma culture et certainement d’autres, qui est edgardoh ?
Un dev assez actif sur darktable dernièrement. Et visiblement il pense comme pas mal d’entre nous car ces modifs sont exactement ce que l’on discute ici, à savoir supporter plusieurs ordre d’exécution des modules. Et si j’ai bien compris c’est même mieux que ce que je décrivais plus haut car il supporte plusieurs ordre simultanément, donc il conserver l’historique des anciens développements 100% intact.
Pour le devellopement c’est ce que j’avais compris aussi mais un point qui n’est pas clair pour l’instant concerne la modification de l’ordre des modules. Si j’ai bien compris, il faudra modifier un fichier source et recompiler ensuite… Chose qui ne sera pas évidente pour les version packager…
Rien n’est encore figer dans le marbre, mais ce que j’ai compris c’est que tout cela sera dynamique. Donc rien à recompiler pour les utilisateurs et dt supportera donc les anciens et les nouveaux historiques. C’est presque trop beau Mais encore une fois rien n’est figée. À suivre donc…
La longeur de la vidéo est très délicat — j’ai essayé quelque fois. Mais ce serait cool d’y arriver et cela passe par définir et contrôler le propos à tenir je pense
En tout cas merci pour la vidéo que tu t’apprêtes à réaliser.
), ensuite forker « agressivement » se serait plutôt dommage car ça risque de casser la dynamique de la communauté DT. Problème assez insoluble.
qui donne des clefs sur l’interface suivi d’une approche de dvpt avec dt?