Forker darktable ? // darktable next-generation ?

[jpg54]

Juste le noeud de taquet .............................. petit joueur !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Allez un que j'aime bien : https://www.lesnoeuds.com/noeud-146-baderne.html aussi dit paillasson.

[jpverrue]

Totalement hors sujet : moi, je sais faire les têtes de turc !

[Roger]

Viens sur Telegram, je partage. En attendant, prends un chouchen de la forêt de Brocéliande à ma santé !

Ok pour le chouchen, mais la foret de Brocéliande c'est un peu surchargé à mon goût (c'est vrai que mon seuil de tolérance est très bas). Je suis plutôt landes & tourbières à terre (la plupart du temps en fait, plus vraiment le temps de mettre les pieds sur un bateau).

Mais j'ai comme l'impression qu'on a un tantinet dérivé du sujet là 

[nicoauffray]

Viens sur Telegram, je partage. En attendant, prends un chouchen de la forêt de Brocéliande à ma santé !

Ok pour le chouchen, mais la foret de Brocéliande c'est un peu surchargé à mon goût (c'est vrai que mon seuil de tolérance est très bas). Je suis plutôt landes & tourbières à terre (la plupart du temps en fait, plus vraiment le temps de mettre les pieds sur un bateau).

Mais j'ai comme l'impression qu'on a un tantinet dérivé du sujet là 

Il y a quelques coins de landes tout près de Brocéliande. Avec tout ça, je propose un coup de bière ou de Chouchen sur un catamaran à proximité de Quiberon

Forker, c'est dériver de l'outil original. Donc dériver du sujet d'origine, on peut dire que c'est forker. Bon, bah ça va, on reste dans le sujet  

[techexo]

Bonjour à tous. Petit nouveau, mais ayant suivi toutes les dernières vidéos d'Aurelien où il a pesté abondamment sur le pipeline de darktable (et à juste titre autant que je puisse en juger), j'avais tout de même quelques remarques (qui sont peut-être inutiles vu que les choses ont l'air d'avancer dans une direction plus supportable).

La première est : dans un contexte de production professionnel de photos, à quelle fréquence on retournera à des vieilles photos déjà traitées ? Si la réponse est "rarement", la question de la rétrocompatibilité est à mon avis superflue tant que l'on peut avoir deux versions de darktable en parallèle. Je suppose qu'un photographe dont c'est le boulot créé suffisamment de matériel pour travailler surtout sur ses dernières œuvres, mais peut-être me trompe-je.

La seconde : dans le cas d'un fork vers un "nouveau darktable" (que j'appellerai -ng), il devrait être possible d'ajouter la version de darktable dans les fichiers XMP et afficher un avertissement "Vous travaillez sur un développement effectué avec une version antérieure de darktable, le rendu risque d'être différent" si l'on ouvre avec darktable-ng, avec un bouton "OK j'update le XMP et j'éditerai ce fichier avec darktable-ng dans le futur". L'utilisateur ferait ainsi le choix volontaire de profiter des nouvelles fonctionnalités de -ng, en toute connaissance de cause.

Enfin, l'exemple de Python est comme cela a déjà été mentionné à double tranchant. Toutefois, il est indéniable que 1) les débutants ne font plus de Python2 ; 2) les développeurs Python, même chevronnés, goûtant aux fonctionnalités spécifiques de Python3 retournent rarement en arrière, particulièrement pour les dernières versions ! 3) il reste tout à fait possible d'avoir les deux en parallèles (même si c'est particulièrement c****t de passer tout le temps de l'un à l'autre). Enfin, sans insulter la communauté darktable, je pense que son impact est tout de même moindre que celui de Python dans le paysage informatique mondial .

De mon point de vue (naïf), je pencherai plus pour un changement de version majeur (darktable3?) afin que la communauté de traducteurs/porteurs/testeurs ne partent pas en courant ; si possible après une négociation avec les développeurs historiques. Dans tous les cas, merci à tous les devs actifs !

[DKT]

Bonjour à tous. Petit nouveau, mais ayant suivi toutes les dernières vidéos d'Aurelien où il a pesté abondamment sur le pipeline de darktable (et à juste titre autant que je puisse en juger), j'avais tout de même quelques remarques (qui sont peut-être inutiles vu que les choses ont l'air d'avancer dans une direction plus supportable).

La première est : dans un contexte de production professionnel de photos, à quelle fréquence on retournera à des vieilles photos déjà traitées ? Si la réponse est "rarement", la question de la rétrocompatibilité est à mon avis superflue tant que l'on peut avoir deux versions de darktable en parallèle. Je suppose qu'un photographe dont c'est le boulot créé suffisamment de matériel pour travailler surtout sur ses dernières œuvres, mais peut-être me trompe-je.

La seconde : dans le cas d'un fork vers un "nouveau darktable" (que j'appellerai -ng), il devrait être possible d'ajouter la version de darktable dans les fichiers XMP et afficher un avertissement "Vous travaillez sur un développement effectué avec une version antérieure de darktable, le rendu risque d'être différent" si l'on ouvre avec darktable-ng, avec un bouton "OK j'update le XMP et j'éditerai ce fichier avec darktable-ng dans le futur". L'utilisateur ferait ainsi le choix volontaire de profiter des nouvelles fonctionnalités de -ng, en toute connaissance de cause.

Enfin, l'exemple de Python est comme cela a déjà été mentionné à double tranchant. Toutefois, il est indéniable que 1) les débutants ne font plus de Python2 ; 2) les développeurs Python, même chevronnés, goûtant aux fonctionnalités spécifiques de Python3 retournent rarement en arrière, particulièrement pour les dernières versions ! 3) il reste tout à fait possible d'avoir les deux en parallèles (même si c'est particulièrement c****t de passer tout le temps de l'un à l'autre). Enfin, sans insulter la communauté darktable, je pense que son impact est tout de même moindre que celui de Python dans le paysage informatique mondial .

De mon point de vue (naïf), je pencherai plus pour un changement de version majeur (darktable3?) afin que la communauté de traducteurs/porteurs/testeurs ne partent pas en courant ; si possible après une négociation avec les développeurs historiques. Dans tous les cas, merci à tous les devs actifs !

[aphyl]

Bonjour, j'utilise Darktable depuis plus d'un an mais voici mon premier post.

Bravo pour votre travail !

Je suis développeur et je suis allé voir dans les sources à propos des priorités des modules.
Chaque module semble définir lui même sa priorité :
Par exemple, ci-dessous pour le module de couleur de sortie.
Comme vous le voyez, j'ai changé la priorité puis recompilé et effectivement dans l'onglet de gauche de la chambre noire, le module est passé avant le sharpen (priorité 742)
fichier colorout.c ligne 729 : module->priority = 741 ; //814; // module order created by iop_dependencies.py, do not edit! ;

Je ne connais pas le fonctionnement du logiciel et ça ne doit pas être si simple de modifier cette priorité, le "do not edit" est assez clair.
Il faut dire que le code de Darktable est un formidable plat de spaghetti, comment s'y prendre pour s'y retrouver facilement ?
En d'autres termes et même si ma question est hors sujet, puis-je savoir avec quels outils de développement vous travaillez sur Darktable.
J'aimerais bien appréhender un peu mieux le code de Darktable, merci !

Cordialement

[pascal]

> puis-je savoir avec quels outils de développement vous travaillez sur Darktable.

Emacs + console tilix

[rawfiner]

puis-je savoir avec quels outils de développement vous travaillez sur Darktable

Atom et vim pour ma part (ça dépend de ce que j'ai à faire). Et git, évidemment 
Après, je m'y retrouve pas toujours facilement, quand j'avais modifié l'aide contextuelle j'avais parfois mis un bon bout de temps pour trouver où étaient créés tel ou tel widget  
Globalement, tout dépend de quelle partie du code t'intéresse, tu es pas obligé de connaitre la base complète pour commencer à faire des choses 

[SeSy]

J'ai peu de temps perso pour la photo mais je passe de temps en temps sur le forum, et je poste quelques fois. Cela fait bien trois ans que je me suis mis à DT. Et je trouve ce logiciel génial, même si j'ai des tonnes d'idées pour encore l'améliorer, notamment dans les idées qui ont pu être précisées dans ce fil comme un ensemble de modules à appliquer sur une sélection zone + paramètres (+ pourquoi pas niveau d'ondelettes) et pas l'inverse de la zone sur le module. Je n'ai pas encore eu le temps de télécharger et utiliser la 2.6 mais les nouveaux modules semble extras.

En revanche et de la même manière que aphyl, j'ai voulu ouvrir le code et voir comment cela fonctionnait... et j'ai aussi trouvé un plat de spaghetti qui m'a fortement inquiété (je ne fais plus de dev depuis plusieurs années, mais mon taf actuel c'est d'encadrer, de coacher et de challenger des équipes de dev). Autant je suis incapable de critiquer les modules et les calculs, autant la partie "info de gestion" me parait à solidifier (ou alors je n'ai vraiment rien compris).

Au final, je suis content qu'il n'y ait pas de fork, diviser les forces, c'est généralement préjudiciable et que de grandes évolutions puissent tout de même voir le jour. Mais même si l'objectif est le développement d'une photo, n'oubliez pas que certains - dont moi - arrivent de LR et attendent aussi de gérer leurs photos et donc aussi un logiciel pérenne de gestion de "collections" et cette partie là me semble bien "artisanale".

En tout cas, merci pour ce superbe boulot.

Je ne connais pas le fonctionnement du logiciel et ça ne doit pas être si simple de modifier cette priorité, le "do not edit" est assez clair.
Il faut dire que le code de Darktable est un formidable plat de spaghetti, comment s'y prendre pour s'y retrouver facilement ?
En d'autres termes et même si ma question est hors sujet, puis-je savoir avec quels outils de développement vous travaillez sur Darktable.
J'aimerais bien appréhender un peu mieux le code de Darktable, merci !