Forker darktable ? // darktable next-generation ?

[rawfiner]

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)

[Andy Costanza]

Sur Lr, il y a une liste déroulante pour choisir la version du processus de traitement https://helpx.adobe.com/be_fr/lightroom/...s_versions
Serait ce faisable sur dt pour assuré la compatibilité avec les anciennes version?

[mimi85]

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.

[dlink]

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 !

[jpg54]

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.

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.

[rawfiner]

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).

[pascal]

- tous les modules peuvent être next-gen (simple)

- 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.

[jpg54]

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.

[rawfiner]

- tous les modules peuvent être next-gen (simple)

- 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 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 ?

[kadomaeurope]

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 :-D qui donne des clefs sur l'interface suivi d'une approche de dvpt avec dt?