retour à LR ...

[aurelienpierre]

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 ? »).