Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Contributor: aurelienpierreForker darktable ? // darktable next-generation ?
#1
Ça fait deux mois que je dissèque l'intérieur de darktable. Deux mois que je découvre un héritage de décisions plus que discutables sur la gestion de la couleur, qui expliquent tout un lot de problèmes et de frustrations depuis plusieurs années. Deux mois que, à chaque fois que je signale ce qui ne devrait pas arriver, on (les 3 principaux développeurs historiques) me répond qu'il ne faut pas casser la compatibilité des fichiers XMP créés avec les versions précédentes. Au prix de maintenir du code cassé dans le logiciel, pour ne pas casser la compatibilité (un comble).

Liste non exhaustive de tout ce qui ne va pas:

- un workflow entièrement basé sur l'utilisation des normes ICC (profils de couleur d'entrée et de sortie), datant de 1976 et pensées pour les écrans CRT (cathodiques), portées à la va-comme-je-te-pousse pour les écrans LCD/DEL, qui devient extrêmement limitant avec les écrans "Wide-Gamut", HDR, 10 bits etc.

- conséquence du workflow ICC, on retouche dans un espace de couleur relatif à l'écran (RGB de sortie), et non relatif à la scène réelle (RGB d'entrée). Il y a 20 ans, les écrans utilisaient tous un espace de couleur (physique) sRGB et n'avaient pas forcément de gestion de la couleur intégrée. On utilisait sRGB en sortie, qui s'affichait alors tel quel sur les écrans/systèmes en couleur non gérée (native).
Or, aujourd'hui, avec la multiplication des supports d'affichage et des espaces de couleurs (sRGB pour les écrans d'ordi, REC 709 pour les TV HD, REC 2020 pour les TV HDR), la sortie n'arrête pas de changer, et se corrige elle-même (via des profils internes). Du coup, ça n'est plus au photographe de gérer la sortie (pourvu qu'il y ait des méta-données dans le fichier image qui disent quel espace de couleur et quelle courbe de réponse sont utilisés), et la seule chose qui ne change pas est l'espace RGB d'entrée. L'académie des Oscars a développé un workflow couleur basé sur une chaîne de travail linéaire relative à la scène et produit du code libre (les ACES) pour aider les développeurs. Ce workflow est notamment utilisé dans des logiciels comme Da Vinci Resolve, et massivement utilisé à Hollywood.

- un ordre des modules immuable (à la limite, ce n'est pas le pire) mais surtout incohérent avec la science de la couleur : les modules de filtrage fréquentiel (passe-haut, passe-bas, ondelettes, netteté, flou, effet Orton) devraient être en début de pipeline, au niveau où il est encore linéaire, pour respecter le théorème de Parseval et la conservation de l'énergie dans les opérations spectrales. De plus, certains modules sont situés après le profil de sortie, donc à réglage identique, leur effet change quand vous changez d'espace de couleur ou d'écran.

- entre le profil d'entrée et le profil de sortie, le pipe est en Lab. AUCUN logiciel de retouche ne travaille en Lab par défaut, mais dans des espaces RGB de référence (Adobe RGB, Prophoto RGB, sRGB, REC 709) car cet espace, en dépit de son apparente facilité d'utilisation (luminosité et couleur entièrement séparés) et de son caractère absolu (indépendant du medium), créée plein d'artifices quand on l'utilise pour manipuler les pixels : désaturation, virage des couleurs, etc. Ces artifices restent modestes tant qu'on ne pousse pas trop les pixels, mais les capteurs HDR récents (Nikon D8xx, Sony A7xx, Phase One, Hasselblad, etc.) imposent des corrections dramatiques qui ne pardonnent plus ces erreurs et imposent des corrections fastidieuses de la couleur pour compenser les dé/sur-saturations qui se produisent après avoir poussé la luminosité. Alors qu'en travaillant directement en RGB, on évite un grand nombre de problèmes (cf mon module filmique).

Liste non exhaustive de tout ce que je voudrais corriger:

- laisser à l'utilisateur la possibilité de travailler dans l'espace de couleur de son choix (Lab, Adobe RGB, Prophoto RGB, ACES P0, REC 2020)

- réécrire tous les modules Lab pour les rendre compatibles avec RGB.

- virer du code toutes les constantes RGB et les corrections gamma codées en dur.

- rendre le workflow basé sur ICC et sur le RGB destination optionnel (display-referred) et intégrer de workflow ACES basé sur l'entrée (scene-referred), plus robuste et reproductible, et surtout 100 % évolutif

- remettre les modules dans un ordre mathématiquement justifié

- éventuellement, ouvrir la possibilité de réarranger l'ordre des modules selon le choix de l'utilisateur.

MAIS

1.Tout ça impose de casser la compatibilité (même si, au pire, les versions antérieures de darktable sont téléchargeables à vie), pas dans le sens où les anciens fichiers de retouche ne pourront plus être ouverts, mais dans le sens où les mêmes réglages n'auront plus les mêmes effets. Et vue l'inertie et la résistance au changement chez les développeurs historiques de dt (heureusement qu'il y a Pascal pour prendre des risques), ces changements sont à peu près garantis de ne jamais passer dans le version officielle.

2. C'est un boulot de dingue qui vise plutôt les pros et les experts en intégrant des outils issus de l'industrie cinéma qui donnent une meilleure reproductibilité et une meilleure pérennité, en autorisant des changements de worflow ultérieur sans avoir à changer (encore) tout le logiciel. Ceci étant, c'est un boulot encore plus massif de maintenir la compatibilité arrière avec du code cassé.

3. Maintenir coûte que coûte la compatibilité arrière aboutit à des paradoxes et mène lentement vers une impasse où le poids de l'héritage ne permet plus de s'adapter au nouveau matériel (appareils photos, écrans, imprimantes) et nouveaux protocoles.

4. Je perds une énergie considérable à essayer de convaincre Roman Lebedev, Tobias Ellinghaus, et dans une moindre mesure Johannes Hannika, qu'il faut faire des changements. Je me fais envoyer promener sèchement quand je propose des changements, et même quand je propose du code pour les réaliser (sans Pascal, mes PR seraient encore en train de pourrir sur Github, sous les commentaires assassins de Lebedev).

DONC

Est-ce que vous pensez qu'on (je) devrait forker darktable ?
Aurélien, photographe portraitiste sur Nancy-Metz
Développeur de filmique.
Dérive de couleur ? Désactivez courbe de base.
Halos clairs ? Désactivez ombres & hautes lumières.
Répondre
#2
(17-11-18, 01:26)aurelienpierre a écrit : DONC

Est-ce que vous pensez qu'on (je) devrait forker darktable ?
Bonjour
Je n'ai absolument aucune compétence pour évaluer le bien fondé ou non de tes remarques.
J'ai, en revanche, une assez bonne expérience de l'action associative, syndicale et politique.
Je suis persuadé qu'il est totalement vain de croire que l'on peut changer les choses de l'intérieur, quand on arrive à des situations de blocage.
Il faut toutefois être bien conscient que ce genre de décision entraîne des haines de grande envergure.
Alain Wasniewski
Windows 8.1-darktable 2.6.2
Canon 650 D. Canon 18-135 mm. Canon macro 100 mm
Répondre
#3
(17-11-18, 01:26)aurelienpierre a écrit : DONC

Est-ce que vous pensez qu'on (je) devrait forker darktable ?

Merci de ces longues explications sur le fonctionnement interne de dt et des soucis que cela provoque et des conséquences à lonq terme, forker me parait indispensable mais cela veut dire qu'il faut aussi gérer le fork et le maintenir ? en auras-tu le temps et les capacités ? (pas de jugement sur ta qualité de ton travail, juste une question Wink

Moi qui réfléchissait à passer sous dt pour mon processus photo cela me fait tout d'un coup fortement hésiter Sad
Nikon D800, Pentax 845D, Noblex 135UC
Nodal Ninja 4, Ultimate Modular, R1
Ubuntu 18.04 / Darktable / PTGui/Hugin / Panotour / Pano2VR
Pas de message privé !! Le forum est fait pour ça sauf question personnelle !!
Répondre
#4
Personnellement, je pense que nous n'en sommes pas là... Vous avez porté une bonne partie des dernières avancées. Je trouve que ça avance très bien comme ça. Après une version de dev parallèle pour "demontrer " que tout fonctionne bien histoire de donner plus de poids à vos derniers développements serait un bon compromis Big Grin

De là à envisager un fork... Confused
"Donne un poisson à un homme, tu le nourris pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours."
Pop Os! 64 Bits Gnome 3.32 Sony A7 et quelques vieux cailloux...
Répondre
#5
Citation :4. Je perds une énergie considérable à essayer de convaincre Roman Lebedev, Tobias Ellinghaus, et dans une moindre mesure Johannes Hannika, qu'il faut faire des changements. Je me fais envoyer promener sèchement quand je propose des changements, et même quand je propose du code pour les réaliser (sans Pascal, mes PR seraient encore en train de pourrir sur Github, sous les commentaires assassins de Lebedev).


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 Smile
Répondre
#6
@Aurélien, je suis assez d'accord avec ton raisonnement. 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.

Sinon je suis aussi d'accord pour dire qu'un fork c'est une guerre terrible, on a déjà vu cela dans l'Open Source Sad Je ne sais pas si j'aurais l'énergie pour cela!

Je comprend que l'intérieur de dt devrait changer, maintenant ne peux t'on pas reprendre les modules un à un. Les nommer avec un suffix "-ng" et les passer progressivement vers du RGB? C'est une première étape. Ensuite dans les préférences on pourrait avoir un mode "legacy" ou "next-gen".

Ça marche pour les iop... Maintenant pour le cœur de dt, je ne sais pas trop....

En gros nous sommes 4 devs cette année, Mathieu, Nicolas, toi et moi. Tous ici, voyons l'avis de chacun.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#7
(17-11-18, 11:05)Carafife a écrit : Après une version de dev parallèle pour "demontrer " que tout fonctionne bien histoire de donner plus de poids à vos derniers développements serait un bon compromis Big Grin

Même avis !

Perdre la compatibilité avec les versions antérieures est tout de même un gros inconvénient : il faut que pouvoir voir que le jeu en vaut la chandelle et rien de mieux que tester pour ça, (c' est bien plus parlant que de longues heures d' argumentations Wink  )

Courage à toi en tout cas ! Smile
Répondre
#8
Il vient d'avoir plusieurs avis et je suis aussi d'accord avec @CaraFife pour faire tourner une version dev à côté de celle officielle. Je pensais aussi à un programme qui pourrait mettre à jour les .xmp anciens pour la nouvelle version.
Je suis aussi d'accord avec toi Aurélien pour une nouvelle approche de la chaîne de traitement de darktable au vu d'un certain nombre de photos que je n'arrive pas à traiter de façon satisfaisante.
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.
Répondre
#9
> 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.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#10
(17-11-18, 14:47)jpg54 a écrit : Je pensais aussi à un programme qui pourrait mettre à jour les .xmp anciens pour la nouvelle version.

Ca, si c'est possible ce serait un vrai plus !!!
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)