Forker darktable ? // darktable next-generation ?

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