17-11-18, 01:26
(Modification du message : 17-11-18, 01:41 par aurelienpierre.)
Ç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 ?
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, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
![[Image: 2FAd4rc]](https://bit.ly/2FAd4rc)
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
