+- Forum darktable FR (https://forums.darktable.fr)
+-- Forum : Photographie (https://forums.darktable.fr/forumdisplay.php?fid=72)
+--- Forum : Sujet Libre (https://forums.darktable.fr/forumdisplay.php?fid=83)
+--- Sujet : retour à LR ... (/showthread.php?tid=4066)
RE: retour à LR ... - aurelienpierre - 10-11-19
Je pense qu'on a atteint les limites de dt 2/3 avec le reordering du pipe : ça marche pas avec les styles, ça pose des problèmes d'import. Sans parler de GTK qui ralentit considérablement le tout et rend certains trucs compliqués pour rien (vu qu'en fait, la plupart des wilgets sont dessinés à la main via Cairo). Puis les 3 paths SIMD/SSE/OpenCL à maintenir… J'ai 2 ans de boulot pour tout optimiser là dedans.
vkdt propose un pipe qui prend le masquage vectoriel et rasterisé dès le départ, avec des modules déplaçables et multi-instanciables dès le départ, une GUI super minimaliste et un seul codepath Vulkan GPU infiniment plus rapide, traduisible vers OpenCL et Metal de Apple. Ça me semble plus rationnel, et je pense que ça serait plus simple de porter la gestion de fichiers de dt vers vkdt que l'inverse.
RE: retour à LR ... - pascal - 10-11-19
Et porter tout le reste... Le module d'impression, le slideshow, la gestion des tags, le module carte....
40 pages plus tard...
Le mode culling.
Vu le boulot je pense que ce sera jamais fait... Mais j'espère le tromper.
RE: retour à LR ... - nicoauffray - 10-11-19
Avoir au moins une version 3.0 portée sur Vulkan avec les apports que tu présentes Aurélien, je prends. Mais avoir Vulkan sans au moins les fonctionnalités actuelles de la 3.0, non merci. Et évidemment, j'image que le travail pour porter tout ça est énorme. Mais c'est à faire entièrement ou ne pas faire selon moi. Évidemment, quand je parle de la 3.0, je ne parle d'un certain nombres de modules anciens, aujourd'hui obsolètes.
RE: retour à LR ... - aurelienpierre - 11-11-19
Le travail sera conséquent sur certaines parties, mais considérablement simplifié sur d'autres.
Les parties traitement d'image sont beaucoup plus simples sous Vulkan (les mêmes fonctionnalités se codent en 4 fois moins de lignes, sans compter qu'on n'a plus besoin d'avoir 3 versions de tout le code). L'optimisation du code se fait à un plus haut niveau (on oublie l'alignement de vecteur à la main), donc les modules seront la partie la plus simple (surtout que tous les trucs complexes style laplacien local, ondelettes et filtre guidé sont déjà implémentés à l'heure où l'on parle).
Pour tout ce qui est gestion de tag et toute la partie purement informatique, ce sont des trucs qui devraient être fait en orienté objet de toute façon. On se complique la vie en C à créer des structures imbriquées qui ne sont rien d'autres que des classes, et à faire à la main ce que C++ fait en natif. Je vois bien comment faire ça en Python, ça me prendrait pas plus qu'une semaine, j'ose espérer que C++ n'est pas trop différent.
Et puis juste virer GTK sera un progrès. Après m'être tapé tout le nettoyage des styles, la programmation de l'interactivité pour l'égaliseur de ton, etc. GTK nous complique la vie plus qu'il ne règle nos problèmes et son API n'arrête pas de changer (tous les 2 ans), il ne sait pas utiliser le GPU et ne se parallélise pas. En plus, on arrive à des trucs complètement débiles : quand on traite une image sous OpenCL, il faut copier la sortie du GPU/vRAM vers le CPU/RAM pour la donner à GTK, qui va la traiter pixel par pixel sur un seul cœur, puis renvoyer l'UI au GPU pour que ça parte sur l'écran. On se paie une pénalité de performance énorme ici, sans compter que GTK redessine aussi les widgets non affichés à l'écran.
Avec Vulkan et imui, on élimine tout ce non-sens. Tout reste sur le GPU et basta. C'est plus facile aussi d'avoir accès à un cache intermédiaire (pour calculer un histogramme ou prélever une valeur à l'écran), sans avoir besoin de faire une copie locale de la mémoire GPU accessible au CPU.
Je pense qu'on perd plus de temps à essayer de tordre darktable 2/3 pour y inclure des fonctionnalités évidentes aujourd'hui, mais pas en 2009, en bricolant un truc non prévu pour ça avec tous les bugs louches que ça génère. Sans compter qu'on traine une liste de modules ni faits ni à faire (Lab et Cie) qu'on ne pourra jamais déprécier parce que ça va faire gueuler. On peut continuer à ajouter des modules cools, mais le pipeline en lui même n'est plus adapté (cf la galère pour avoir une édition interactive dans l'égaliseur de tons, et je ne sais même pas comment je vais m'en sortir pour la partie OpenCL), et le changer à chaud va être autrement plus corsé que la réorganisation des modules.
Faut voir aussi que la gestion des masques, ajoutée un peu à l'arrache en cours de route, est pleine de défauts aussi. Le simple fait que les paramètres de masquage d'un module dépendent de la sortie des modules précédents est une catastrophe ergonomique. Dans vkdt, j'ai poussé pour que les masques soient gérés séparément au début du pipe (en linéaire, en passant), de sorte que le découpage de l'image en régions paramétrées soit indépendant des modules précédents (et qu'on puisse charger une zone avec des filtres, comme dans lightroom ou dans l'approche U-Points, au lieu de recharger les zones pour chaque module - trop long).
Du coup, repartir d'une feuille blanche, certes c'est plus de boulot, mais c'est moins de contraintes, et on peut faire de la vraie conception d'outil (du problème utilisateur vers l'implémentation), pas juste du bricolage de gadget (« j'ai codé ça ce week end, c'est cool, pouvez-vous l'intégrer ? »).
RE: retour à LR ... - Cailloux - 11-11-19
Bonjour,
Mes connaissances dans le domaine sont des plus limités mais j'ai quand même envie de dire qu'Aurélien est dans la bonne voie.
+1 pour Aurélien donc
RE: retour à LR ... - pascal - 11-11-19
> Et puis juste virer GTK sera un progrès.
Je ne pense vraiment pas! Gtk est vraiment une des meilleures toolkit. Mais bon visiblement le monde entier semble aime le bashing gratuit, il ne faut pas obligatoirement prendre tout pour argent content. Qt est aussi une catastrophe pour d'autres. On fait quoi? Une interface en VT100 ? Va trouver un toolkit que l'on peut changer en CSS...
Ok pour Vulkan, mais pour faire avancer le smilblic il fallait faire un proto est un design d'intégration dans le dt actuel. Il est illusoire de penser que dans l'autre sens ça marchera; On va se retrouver avec deux dt et la fusion sera très très pénible. Ça me fait penser au projet GCC, EGCS si mes souvenirs sont bons qui a foutu un bordel monstre sans vraiment faire aider à faire progresser le projet GCC. Il ne faut pas se leurrer, tout développement est complexe et difficile, penser que tout bazarder pour aller vers de plus verts pâturages n'est souvent qu'une illusion qui ne dure pas très longtemps.
Je pense qu'en y réfléchissant un peu, intégrer Vulkan dans le dt actuel était possible (difficile mais possible) et on aurait déprécié progressivement l'ancien pixelpipe.
> Du coup, repartir d'une feuille blanche, certes c'est plus de boulot, mais c'est moins de contraintes, et on peut faire de la vraie conception d'outil
Oui sauf que l'on va fragmenter un peu plus un projet déjà en sous effectif. Et qui va migrer vers vkdt et refaire ses développements? Hanatos qui a été garant de préserver coûte que coûte la compatibilité ascendante propose un autre projet parfaitement incompatible avec dt actuel. En plus il quitte le navire sans me donner la possibilité de gérer dt actuel correctement (je ne suis toujours pas manager du GitHub). Un jour j'en aurai assez et trop de pression et je quitterais le navire, ce sera un projet Open Source de plus mort.
RE: retour à LR ... - aurelienpierre - 11-11-19
> Je ne pense vraiment pas! Gtk est vraiment une des meilleures toolkit.
Purée, qu'est-ce que ça doit être les autres ^^. Les 3/4 de l'interface dt sont peints directement en dessinant des rectangles via Cairo, on traîne GTK essentiellement pour dialoguer avec l'OS et fournir les fenêtres, mais du coup on est obligé d'ajouter des couches de customisation par dessus, si bien qu'à la fin, ça irait plus vite de juste peindre les pixels à la main dans une boucle.
Le thémage via CSS de GTK est encore très béta, avec des règles CSS3 toujours pas implémentées et des comportements non reproductibles d'un OS à l'autre (cf la liste de font-family qui provoque un segfault sous MacOS… imagine si un site web mal codé faisait planter Firefox…). Dans l'absolu, CSS n'est pas une fin en soi, on veut juste une interface thémable avec un fichier texte, qui va essentiellement se limiter à définir des couleurs et tailles de texte… Ça sera pas long à réimplémenter.
Sérieusement, maintenant, ça me prend moins de temps de réimplémenter mes fonctions et de les spécialiser que d'essayer de comprendre comment faire marcher des libs tierces « tous usages » dont on utilise 25% des fonctionnalités et dont on ramasse 99% des bugs), sans parler des pénalités de performances. Mêmes les devs de Gimp ne peuvent plus voir GTK en peinture.
RE: retour à LR ... - pascal - 11-11-19
> Sérieusement, maintenant, ça me prend moins de temps de réimplémenter mes fonctions et de les spécialiser que d'essayer de comprendre comment faire marcher des libs tierces
C'est la cas pour tout le monde... Et un jour faut maintenir tout ce code plutôt que de se baser sur des bibliothèques qui vont mûrir et proposer des fonctionnalités avancées avec le temps qui simplifie toujours la tâche.
> Mêmes les devs de Gimp ne peuvent plus voir GTK en peinture.
Référence? Un dev? Deux devs? Mais certainement pas tous les autres qui sont des devs des deux projets intimement liés.
RE: retour à LR ... - aurelienpierre - 11-11-19
> Et un jour faut maintenir tout ce code plutôt que de se baser sur des bibliothèques qui vont mûrir et proposer des fonctionnalités avancées avec le temps qui simplifie toujours la tâche.
Mais j'ai pas l'impression que GTK nous simplifie quoi que ce soit. Il faut répercuter leur changements d'API régulièrement, ça génère du travail de nettoyage et de maintenance périodique. Somme toute, on ne faut que dessiner des rectangles sur un écran. Est-ce qu'on a vraiment besoin de tout le bloatware GTK ?
Voir https://discuss.pixls.us/t/processing-that-sucks-less/13016/76 pour avoir une idée de la réactivité du pipe, traité en pleine résolution, avec le laplacien local…
> Référence? Un dev? Deux devs? Mais certainement pas tous les autres qui sont des devs des deux projets intimement liés.
Mitch et Pipin.
> Je pense qu'en y réfléchissant un peu, intégrer Vulkan dans le dt actuel était possible (difficile mais possible) et on aurait déprécié progressivement l'ancien pixelpipe.
On peut pas déprécier progressivement, le changement du pipe doit se faire en une fois pour tous les modules. L'idée est d'avoir le traitement d'image et l'UI calculés au même endroit. Je ne vois aucun moyen de faire ça de façon incrémentale, c'est trop bas niveau dans le logiciel. Sans compter qui personne ne comprend réellement tout ce qui se passe dans le pipeline, il y a des branchements partout pour l'OpenCL, c'est un bateau rouillé qui tient grâce à la peinture.
> Et qui va migrer vers vkdt et refaire ses développements?
On peut très bien réimporter les développements en passant par les XMP… On sait quels algo sont utilisés dans dt 2, il suffit de rediriger leurs paramètres à la bonne place.
> Hanatos qui a été garant de préserver coûte que coûte la compatibilité ascendante propose un autre projet parfaitement incompatible avec dt actuel. En plus il quitte le navire sans me donner la possibilité de gérer dt actuel correctement (je ne suis toujours pas manager du GitHub). Un jour j'en aurai assez et trop de pression et je quitterais le navire, ce sera un projet Open Source de plus mort.
Oui, ça c'est un autre problème : l'absence de gestion de projet.
RE: retour à LR ... - jpg54 - 11-11-19
Non, non @pascal ne quitte pas le navire ! Les eaux sont très profondes là ou vous êtes /
