Prochaine mise à jour

[manu]

Si si... mais on n'en parlera pas non plus. :-D

[olliwa]

De mon point de vue, ce schisme dt / rdt était inévitable.
Ce n'est pas une catastrophe comme certains le craignent, ça va donner plus de souplesse aux développements
Personnellement, n'utilisant quasiment que la "chambre noire", cette branche m'intéresse
Je vote pour la suppression aussi de la carte et du diaporama.

J'ai pensé à d'autres noms pour cette nouvelle branche :
"dtopp" : darktable only photo proccessing
"dtkis" : darktable keep it simple
"dtlite"
"dtn4g" : dartable not for geek

mon préféré qui devrait faire sourire Aurélien :
"dtMoka" : darktable cafetière moka de Bialetti
voir https://fr.wikipedia.org/wiki/Alfonso_Bialetti

Il me reste plus qu'à apprendre à compiler dt pour debian et pour windows

[pascal]

> Ce n'est pas une catastrophe comme certains le craignent, ça va donner plus de souplesse aux développements

Si c'est une catastrophe comme pour tous les projets forkés. Et j'ai une bonne dose d'expérience, voir GCC il y a longtemps... Diviser une petite communauté n'est jamais gagnant.

> Je vote pour la suppression aussi de la carte et du diaporama.

Voilà le problème, chacun y va de sa petite idée sans se poser la question des "autres" ! Un projet Open Source doit être fait pour le plus grand nombre. Si tu n'utilises pas carte et diaporama... Pourquoi diable les supprimer alors qu'ils ne sont même pas visible par défaut. Penser partage, libre, communauté ne semble pas donner à tous le monde, chacun préfère essayer d'imposer sa vision.

[aurelienpierre]

> Diviser une petite communauté n'est jamais gagnant.

Alors que les unir dans l'inefficacité, le design bâclé et les assommer sous une myriade d'options qui servent à 3 pelés, c'est gagnant. Sans parler des comportements étranges et pas systématiquement reproductibles parce que toutes ces options interfèrent de façon imprévisible, et quand tu ouvres le code, tu te fais abattre par des fichiers de 4000 lignes de spaghetti où tu trouves du SQL dans des fonctions censées dessiner du Gtk et des if imbriqués sur 4 à 5 niveaux qui testent des trucs non uniformes pour patcher tous les bugs trouvés.

Sérieusement… Un outil, ça sert à faire un travail. Les communautés se font et se défont autour d'outils que les gens trouvent adaptés à leurs besoins. Je suis pas Sauron, je vois pas l'intérêt de les unir dans les ténèbres. Le meilleur logiciel est celui qui me permet de sortir un maximum d'images en un minimum de temps avec le look que je voulais. Les querelles de clocher, c'est pour les intégristes et les fondamentalistes.

Et je ne crois pas une seule seconde au logiciel taille unique. La taille unique, c'est celle qui ne va à personne.

[aurelienpierre]

D'ailleurs, en parlant de diviser la communauté, je voudrais pas dire mais… Il suffit d'aller voir sur le forum francophone de Art (fork de Rawtherapee : https://forum.artherapee.fr/) pour se rendre compte qu'on y retrouve plein de gens qui étaient actifs ici même il y a 5-6 ans. Il a même été fondé par un certain Carafife…

Ce qui est intéressant, c'est que précisément, Art est un Rawtherapee dégraissé. Y a des leçons à en tirer, non ?

[FrançoisH]

De mon point de vue, ce schisme dt  / rdt était inévitable.
Ce n'est pas une catastrophe comme certains le craignent, ça va donner plus de souplesse aux développements
Personnellement, n'utilisant quasiment que la "chambre noire", cette branche m'intéresse
Je vote pour la suppression aussi de la carte et du diaporama.

J'ai pensé à d'autres noms pour cette nouvelle branche :
"dtopp" : darktable only photo proccessing
"dtkis" : darktable keep it simple
"dtlite"
"dtn4g" : dartable not for geek

mon préféré qui devrait faire sourire Aurélien :
"dtMoka" : darktable cafetière moka de Bialetti
voir https://fr.wikipedia.org/wiki/Alfonso_Bialetti

Il me reste plus qu'à apprendre à compiler dt pour debian et pour windows

Bonjour,

quand Adobe a désactivé la carte sur le LightRoom version boite que j'avais, ça m'a foutu en pétard. Beaucoup d'appareils modernes ont un gps intégré, ce n'est pas mon cas mais j'aime bien savoir où j'ai pris telle ou telle photos, et peut aussi intéresser celui qui la regardera, donc pendant que c'est chaud je les pointe sur la carte et met à jour le raw, le jpg est ainsi geotaggé direct. C'est une des premières raisons pour laquelle j'ai apprécié de trouver darktable sur mon chemin.
Je rejoins Pascal sur ce point, moi ce sont les collections que je n'utilise pas ou très peu, elles ne me gênent pas pour autant. 

[jpg54]

J'ai un peu regardé les discussions en anglais ou je n'ai pas tout compris vu que j'utilise la traduction en ligne et suis certainement passé à côté de subtilités de la discussion.
Mais je vais revenir sur les règles de la programmation structurée (cours de programmation du CNAM) :
un programme doit avoir une entrée et une seule sortie (même les sous-programmes) ce qui évite les exit intempestifs et autres goto ;
les boucles et sélections imbriquées doivent être décomposées en sous structures en respectant la première règle ;
on sépare les appels systèmes et les appels d'autres langages externes sont séparés de la structure principale du langage de programmation.
Ces méthodes permettent une lecture facile des lignes de codes et facilitent la documentation du code.
Ca me rappelle l'usine à gaz qui gérait l'introduction de module dans le pipe-line avec des calculs en réels alors qu'une liste chaînée aurait réalisé cette gestion facilement.

---

Ca ne rappelle mes première discussion avec Aurélien par dessus la grande bleu. Pour arriver à cette programmation structurée : https://www.google.com/search?client=fir...rammatique fut une révélation pour remplacer l'ancestral organigramme que je n'ai jamais réussi à m'approprier et j'en était arrivé à l'écrire après le programme !!!!!!!!!!! Quelle ineptie !!!!!!!!!!!!

[olliwa]

yep, compilation ok sur wsl2 en suivant la procédure décrite dans le git - finalement très simple
le plus long a été d'installer toutes les dépendances
il me reste à tester la compilation sous windows

merci à tous les acteurs de dt et rdt, les devs, les traducteurs, et tous les autres qui s'occupe de la doc et des tutos et à ce forum

[aurelienpierre]

Lightroom a viré la carte parce qu'ils utilisaient les fonds de cartes Google Maps, pour lesquels Adobe payait une licence mensuelle en fonction du nombre d'utilisateurs, et que Google a monté ses tarifs en cours de route. La version boîte ne générant pas de revenus récurrents, ils est parfaitement logique qu'ils aient coupé les frais, le principe fondamental du business étant que la somme des rentrées soit au moins supérieure à la somme des sorties d'argent.

De l'autre côté, je voudrais quand même rappeler que tout widget Gtk déclaré dans la fenêtre de l'appli est calculé par le processeur, qu'il soit visible ou caché à l'écran. Donc tout ce qui est dans darktable coûte du calcul juste pour être là. Et on a actuellement un gros bug (depuis quand… ?) qui conduit toutes les icônes des boutons de l'interface à être redessinées à chaque fois que le curseur bouge dans la fenêtre, même s'il bouge sur du vide, et même pour les boutons cachés. Idem pour l'histogramme de la chambre noire : chaque mouvement de souris déclenche un recalcul, même si la souris ne survole pas l'histogramme. C'est des cycles processeurs gaspillés dans tous les sens. Il suffit de démarrer darktable avec

Code :

darktable -d all

pour voir dans la sortie de la console la quantité de trucs qui se déclenchent à chaque mouvement de souris, c'est invraisemblable (et y a pleins de choses dupliquées, comme des requêtes SQL qui auraient dûes être mises en cache).

Donc la sobriété et la modération, c'est pas juste quand il s'agit de prendre les transports en commun ou le vélo. C'est pas parce qu'on peut ajouter des trucs qu'on doit. Tout ce qu'on ajoute a un prix, donc y a un arbitrage à faire entre le bénéfice et le coût. Le traitement de pixels est assez lourd en lui-même pour ne pas faire exprès de charger la mule sur des gadgets graphiques.

Autant dire que je suis en complet désaccord avec Pascal sur les priorités et les orientations du projet. Et, quand je parle d'orientations, on est plus dans la France de 1939 : tout rentre. À force de chercher à ne froisser personne, on emmerde tout le monde.

[Manu38]

A vous lire j'ai l'impression que vous décrivez ce qu'il se passe dans mon boulot:
1- Le client réclame toujours plus de nouvelles fonctionnalités
2- L'équipe de dev explique que c'est compliqué car il y a déjà beaucoup de dette technique dans le code (le nom politiquement correct pour dire "code de merde") et qu'il faudrait passer du temps à la résorber.
3- C'est le client qui paye donc c'est lui qui a raison à la fin.
4- On rajoute une couche de code pourri sur le code pourri.

On réitère ce cycle depuis 15 ans et le point de rupture n'est plus très loin : un logiciel impossible à maintenir, à faire évoluer, à optimiser...
Mais le court terme étant toujours la priorité, il faudra que ça pète une bonne fois pour toute en production pour que le client s'en rende compte. J'espère pour lui que ça ne sera pas déjà trop tard.

Bref, tout ça pour dire qu'un fork en soit n'est pas une mauvaise chose surtout quand il s'agit de vouloir repartir sur des bases saines.

L'avenir dira qui a raison mais de mon point de vue darktable contient déjà un nombre de fonctionnalités extraordinaire. Je ne ressens pas de manque à ce niveau là.
Par contre niveau performances, avec le nombre de pixel allant toujours plus haut il est clair qu'avoir un pipeline de traitement optimisé est important à la fois pour préparer l'avenir avec des algos plus poussés et aussi pour avoir une empreinte énergétique plus limitée.