Forker darktable ? // darktable next-generation ?

[Baude]

> L'idée de Pascal d'avoir 2 versions différentes d'un module est très séduisante mais certains vont encore dire que darktable est trop complexe.

L'idée c'est d'avoir une pref pour passer 100% aux modules NG. Par défaut on ne les voit pas. Les conservateurs seront contents et les autres aussi.

Salut à tous !

Le problème d'avoir deux versions c'est que c'est plus ou moins deux fois plus de boulot de dev non ? C'est à vous de voir Pascal et Aurélien mais si ça doit durer longtemps ce serai dommage que vous lâchiez le projet.

[jpg54]

> L'idée de Pascal d'avoir 2 versions différentes d'un module est très séduisante mais certains vont encore dire que darktable est trop complexe.

L'idée c'est d'avoir une pref pour passer 100% aux modules NG. Par défaut on ne les voit pas. Les conservateurs seront contents et les autres aussi.

Tout à fait d'accord Pascal et le découpage des modules de darktable en sous ensembles indépendants doit se prêter très bien à développer et à maintenir. AMHA

[mimi85]

jpg54 a écrit : Je pensais aussi à un programme qui pourrait mettre à jour les .xmp anciens pour la nouvelle version.

Ca, si c'est possible ce serait un vrai plus !!!

Les xmp étant des fichiers texte, il doit être possible d'interpréter l'ancien format pour le mettre dans la coque du nouveau en appliquant les modifications. Mais es ce vraiment viable ou/et faisable ???

[aurelienpierre]

> L'idée de Pascal d'avoir 2 versions différentes d'un module est très séduisante mais certains vont encore dire que darktable est trop complexe.

L'idée c'est d'avoir une pref pour passer 100% aux modules NG. Par défaut on ne les voit pas. Les conservateurs seront contents et les autres aussi.

Le problème d'avoir des modules legacy and ng, c'est quand on veut refactoriser les libs : ça fait (une version C + une version SSE + une version OpenCL) × (une version legacy + une version NG) à mettre à jour, tester etc. Là je suis en train de refactoriser les profils de couleur d'entrée/sortie pour que les modules puissent les utiliser sous forme d'API unifiée, typiquement c'est ça qui va poser problème.

À la limite, ça serait plus simple de garder une version 2 avec des mises à jour de maintenance, de lancer une version 3 non compatible, et de faire des backports ponctuels. Comme Python l'a fait.

Tu as vu le problème de la pipette globale… Pour régler ça proprement, c'est tout le pipe couleur qu'il faut assainir.

Ensuite, 1 module = 1 I/O. En C/SSE, c'est pas très grave, mais en OpenCL, 25 % à 66 % du temps de calcul, c'est des I/O entre la RAM et la vRAM. On gagnerait à combiner les "mini-modules" ensemble (genre {saturation + contraste de couleur + vevia + vibrance}, puis {contraste + niveaux + courbes}, puis {colorisation + virage partiel}). Parce qu'encore une fois, cette architecture modulaire n'a du sens que si les modules peuvent être ré-arrangés. Dans le contexte actuel, ça fait juste des I/O pour rien.

Les xmp étant des fichiers texte, il doit être possible d'interpréter l'ancien format pour le mettre dans la coque du nouveau en appliquant les modifications. Mais es ce vraiment viable ou/et faisable ???

Le format de fichier ne va pas changer, et les réglages seront toujours lisibles. Ce n'est pas là que la non-compatibilité se situe. Si on change l'ordre des opérations, et la nature des opérations (fonctions de tranfert, espace de couleur), les même réglages sous darktable 2 ou next-gen n'auront plus exactement les mêmes effets.

Bienvenue dans le monde cruel des développeurs. Je te comprend sur ce point mais faut que tu sois patient. Eux ils sont là depuis un moment et toi tu débarques en voulant tout chambouler (même avec de bonnes intentions). Sois patient et résiste, avec le temps ils changeront sûrement d'avis en voyant à quel point tu contribues au projet et avec le soutien de pascal

C'est pas seulement ça. Les 3 mousquetaires du début n'ont plus le temps/plus l'envie de s'investir dans le projet, ce qui fait qu'à chaque fois qu'on les voit intervenir, c'est pour dire non, et je les soupçonne de prendre le moins de risques possibles sur les nouvelles fonctionnalités pour ne pas se créer du travail en maintenance et correction de bugs derrière. On ne peut pas leur en vouloir, mais à un moment donné, un logiciel qui ne casse jamais est un logiciel qui meurt à petit feu. Je leur ai proposé un financement participatif pour qu'ils prennent quelques heures de congé par mois pour régler les bugs et examiner les contributions de code, je n'ai pas eu de retour. 

Ensuite, il n'y a pas de design dans darktable : chacun amène son code, on intègre ou pas, mais il n'y a pas de souci de cohérence, de réflexion sur la méthode de retouche, etc. Ellinghaus avoue lui-même qu'il n'a pas le temps de regarder ce que font les autres logiciels ni comment ils travaillent. Règle de base : on ne peut pas être brillant tout seul dans son coin. Il y a des recherches qui sont faites sur les bonnes pratiques d'édition d'images, le service R&D de l'académie des Oscars est un très gros contributeur opensource, les ignorer c'est rester coincé en 2010 tout en étant convaincu d'être à la pointe.

Ce qui m'inquiète aussi, c'est que les devs historiques développent darktable « pour le fun ». Moi, je n'ai aucun fun à programmer, je déteste C, je programme pour faire de meilleures photos, et avoir un outil plus robuste, fiable et performant pour y arriver. En ce moment, Hanatos s'est lancé dans une interface simplifiée pour darktable. Considérant que le pipe couleur n'est pas cohérent, c'est une drôle de priorité. Les besoins des photographes sont relégués au second plan. Mais darktable, bien que libre, appartient à Hanatos plus qu'à Pascal, même si la liste des commits depuis un an suggère le contraire.

Note que quelques messages passés sur IRC m'ont été remonté et par exemple Hanatos n'est pas content du tout avec le changement de la position du module de recadrage. Je vais devoir m'expliquer... Bon c'est jamais simple.

C'est vrai que mettre rotation/recadrage juste derrière la correction de perspective, c'est une idée bizarre

Dans l'absolu, j'ai juste envie d'avoir un logiciel opensource de traitement photo de niveau commercial. Je commence à comprendre à peu près ce qui se passe dedans. S'il faut qui j'y bosse à temps plein et qu'il y a des gens prêts à payer mon loyer pendant ce temps là, je réfléchis même pas, je fonce… Le problème, c'est que je ne peux pas assurer la maintenance pour Windows, Mac, et les architectures ARM.

C'est sûr que forker, c'est pas forcément sympa, mais en même temps c'est ça aussi l'OpenSource : quand on n'a plus les mêmes priorités, on divorce (Krita/Gimp, Gnome/Cinnamon/Budgie/Mate, Debian/Ubuntu/Mint).

darktable marche bien tant qu'on ne le pousse pas trop fort, le problème c'est les retouches « extrêmes ». Et avec les derniers ajouts de Heiko Bauke et Edgardo, on a des fonctionnalités de haut niveau empilées sur une base bancale. Et juste pour ça, ça vaut la peine de nettoyer, avec ou sans l'accord des 3 mousquetaires, et quitte à perdre la compatibilité arrière.

[valmy]

DONC

Est-ce que vous pensez qu'on (je) devrait forker darktable ?

Bonjour
Je n'ai absolument aucune compétence pour évaluer le bien fondé ou non de tes remarques.
J'ai, en revanche, une assez bonne expérience de l'action associative, syndicale et politique.
Je suis persuadé qu'il est totalement vain de croire que l'on peut changer les choses de l'intérieur, quand on arrive à des situations de blocage.
Il faut toutefois être bien conscient que ce genre de décision entraîne des haines de grande envergure.

Comme alwa je n'ai aucune compétence pour juger de la situation. En fait vous êtes devant un choix :
- Rester à l'intérieur du système sans possibilité de changer vraiment les choses "quand on arrive à des situations de blocage"
- Faire un fork et subir "des haines de grande envergure"
Cool ... 
A-t-on déjà vu qu'un fork dépassait l'original en qualité ?

[aurelienpierre]

DONC

Est-ce que vous pensez qu'on (je) devrait forker darktable ?

Bonjour
Je n'ai absolument aucune compétence pour évaluer le bien fondé ou non de tes remarques.
J'ai, en revanche, une assez bonne expérience de l'action associative, syndicale et politique.
Je suis persuadé qu'il est totalement vain de croire que l'on peut changer les choses de l'intérieur, quand on arrive à des situations de blocage.
Il faut toutefois être bien conscient que ce genre de décision entraîne des haines de grande envergure.

Comme alwa je n'ai aucune compétence pour juger de la situation. En fait vous êtes devant un choix :
- Rester à l'intérieur du système sans possibilité de changer vraiment les choses "quand on arrive à des situations de blocage"
- Faire un fork et subir "des haines de grande envergure"
Cool ... 
A-t-on déjà vu qu'un fork dépassait l'original en qualité ?

1. définis "qualité" ? (la définition ISO 9001 c'est « aptitude d'un produit à satisfaire les besoins du client »)
2. Libre Office vs. Open Office, Budgie vs. Gnome Shell, Owncloud vs. Nextcloud, Krita vs. Gimp, TeXstudio vs. TeXmaker…

Mais, en fait, l'objectif n'est pas nécessairement de faire mieux, simplement de résoudre des problèmes posés par l'architecture actuelle, qu'on pourra contourner pendant encore un certain temps, mais pas indéfiniment. Et plus on attend, plus le boulot va être difficile parce qu'on accumule le code et les solutions de contournement/spaghetti dans le code.

[bibifric05]

Liste non exhaustive de tout ce qui ne va pas [...]

Est-ce que vous pensez qu'on (je) devrait forker darktable ?

Comme je l'ai souvent dit ici, le principe de la retouche locale pourrait être amélioré en choisissant l'approche classique "sélection d'une zone" puis "application d'un ou plusieurs modules sur la zone" et non l'inverse. Je sais qu'on peut rappeler les masques dessinés, etc. mais ce n'est pas du tout intuitif...

Inkscape est un très bon exemple de fork réussi...

Après, il ne faut pas se leurrer, un tel fork nécessiterait un énorme boulot avec un noyau dur de développeurs ouverts aux idées et critiques des utilisateurs. Et capables de gérer l'aspect multiplateforme (Windows, Mac, Linux, par ordre de nombre d'utilisateurs)...

Bon courage à toi si tu te lances...

Un modèle économique (j'en vois qui s'étranglent au fond de la salle) pourrait être de maintenir le logiciel libre et gratuit et de faire payer les profils des appareils nouveaux pendant une certaine durée de temps. Par exemple, le profil du dernier Fuji moyen format serait payant pendant 3 ou 5 ans, puis deviendrait gratuit.

Il pourrait y avoir des modules payants, etc.

Les développeurs ne vivent pas tous d'eau fraîche (pour l'amour, c'est râpé depuis longtemps) et un logiciel de retouche photo RAW n'est pas un logiciel comme les autres : il nécessite du matériel et des mises à jours constantes, sinon il devient obsolète en quelques mois...

[rawfiner]

@Aurélien, comme Pascal je suis d'accord avec ton raisonnement.
Avoir une "cassure" de compatibilité me parait aussi inévitable pour que darktable puisse continuer à progresser, à la vue de tes explications.
S'il est possible d'éviter le fork en ayant une option "next-gen" qui aurait ses propres modules, avec un ordre différent que la version ancienne, cette solution me parait intéressante.
Si tu penses que les changements à faire sont trop profonds pour cela, alors un fork est nécessaire. Sur ce point, je me fie entièrement à toi, mes connaissances en retouche photo et dans l'architecture du code de darktable sont encore limitées.
Dans tous les cas, je pourrai t'aider pour du test/debuggage, mais si je ne pourrai pas y consacrer un trop gros volume horaire. Je crois qu'il faut que tu évalues si tu as l'énergie et le temps pour faire ça (tout en ayant en tête qu'il faut aussi prendre du temps pour tes autres loisirs, tes amis, dormir, faire des photos, tes études etc), mais je me doute que tu y as déjà réfléchi.
Vu l'ampleur du travail à faire dans les 2 cas, peut être faire un appel aux dons ?

Pour résumer/clarifier ma position : je ne me sens pas compétent pour savoir s'il faut forker ou non. Par contre, je te sens compétent pour le décider, et je compte bien t'encourager pour le gros boulot qui s'annonce ! 

[jpg54]

Je suis aussi prêt à faire des tests comme je l'ai toujours fait depuis que je compile darktable, sauf qu'avant je ne remontais pas mes observations car devait être en anglais.

[mmoy]

De mon côté, je très frileux a l'idée d'un fork.

Déjà, parce que je pense qu'il ne faut pas sous-estimer l'importance de la compatibilité entre versions. On parle d'un éditeur non-destructif : avec darktable, on ne sauvegarde pas le résultat de la retouche, mais le moyen d'y arriver. Donc, sans un darktable qui sache le lire et l'appliquer à un raw, un .xmp n'est pas exploitable. Si darktable fait des changements incompatibles, ce sont les centaines d'images traitées avec les vielles versions qui sont à mettre à la poubelle. Alors OK, je pourrais toujours installer un vieux darktable pour reprendre ces traitements, mais combien de temps le vieux darktable sera-t-il installable et utilisable ? Vu la quantité de dépendances de darktable, il ne faut pas s'attendre à ce que les versions d'aujourd'hui continuent à marcher dans plusieurs années sans effort de maintenance.

Python 3 a été cité dans ce thread, et j'ai l'impression que c'était cité comme modèle de ce qu'il faut faire. Python 3 est sorti en 2008, et dix ans plus tard on n'est toujours pas sorti du merdier que le cassage de compatibilité a entraîné. Je ne connais pas grand monde qui ait subi cette transition et qui considère ça comme un exemple à donner.

Après, forker au sens « écrire du nouveau code », c'est la partie la plus facile. Non pas que ce soit facile d'écrire du nouveau code, mais ça reste la partie émergée de l'iceberg comparé à la maintenance de ce nouveau code à long terme (n'importe quelle étude sur la répartition des coûts dans le développement d'un logiciel vous confirmera que le développement initial est petit devant tout le reste), la construction d'une nouvelle communauté de développeurs, l'animation d'une communauté d'utilisateurs, ...

C'est facile de trouver quelques exemples de forks qui ont réussi et plus difficile de lister les forks qui ont échoué pour une raison très simple : les forks qui ont raté, vous n'en avez jamais entendu parler. Mais moi, les fois où j'ai vu un développeur se plaindre du développement d'un soft et commencer son fork, ça n'a en général pas donné des LibreOffice et des NextCloud, mais plutôt un développeur qui part dans son coin, qui fait un truc pas mal pendant quelques mois puis qui jette l'éponge parce qu'il se démotive.

Par exemple, dans la liste de ce que le « darktable next generation » devrait faire, PhotoFlow coche la plupart des cases : http://aferrero2707.github.io/PhotoFlow/. Sur le papier, ça a l'air à peu près parfait. Mais si on regarde les indicateurs de bonne santé de la communauté : https://github.com/aferrero2707/PhotoFlo...ntributors Vs https://github.com/darktable-org/darktab...ntributors par exemple, ça ne donne pas envie de miser sur PhotoFlow pour l'avenir.