Compatibilité : à quel point ça sert ?

[aurelienpierre]

Dans le développement de darktable, la compatibilité est une contrainte constante. Une image retouchée sous darktable 1.x ou 2.x doit pouvoir s'ouvrir et s'afficher de façon identique sous darktable 2.6.

Problème : on est obligé de trimballer du code à moitié fonctionnel depuis parfois longtemps.

Mais…

En discutant avec des graphistes professionnels, je me suis rendu compte de 2 choses :

1. c'est rare qu'on revienne sur d'anciens travaux
2. quand ça arrive, la première réaction qu'on a est de recommencer le boulot, parce que ce qu'on faisait il y a des années nous paraît moche et que les logiciels ont évolué pour faciliter des trucs qu'on faisait au moyen de bricolages immondes il y a des années.

Par exemple, quand je vends un tirage, je repasse toujours sur le raw en vitesse, souvent pour désactiver des trucs louches et épurer l'historique.

Du coup, je me demandais : à quelle fréquence la compatibilité vous sert réellement ?

[Nicolas]

Personnellement la compatibilité ne me sert pas particulièrement, mais cela ne fait pas très longtemps que j’utilise Darktable à plein temps (2 ans environ) donc je suis peut-être moins sujet à cette dépendance (j’ai commencé sur la version 2.2).
Ceci dit, si je dois revenir sur une vieille photo c’est que le traitement fait à l’époque ne me convient pas et par conséquent je préfère repartir à zéro sur une meilleure base avec une chaîne de traitement que je maîtrise bien mieux qu’à mes débuts.
Du coup, je trouve ça dommage de limiter le développement et l’amélioration de Darktable et surtout de s’empêcher de faire du ménage dans la liste des modules maintenant désuets juste pour conserver une rétrocompatibilité avec des vieilles versions.
Peut-être peut-on au moins retirer les modules inutiles de la version 1.x sans toucher pour le moment à ceux de la version 2.x si cela est possible ?

[philippus]

Personnellement, je répondrai un peu de la même manière ...

Quand j'ouvre une ancienne photo, une ancienne belle photo, je la retravaille systématiquement avec les nouveau module disponible.

Et comme te le disait certains graphistes Aurélien, je les retravaille car je les trouve assez moche par rapport a ce que je suis capable de faire aujourd'hui en matière de développement.

Donc que certains anciens outils disparaissent ne me gène en rien ...

[jpg54]

J'ai un avis un peu différent, j'utilise darktable depuis les premières versions, je ne cherche pas à récupérer des traitements anciens mais il faudrait un système qui permet de faire une purge des anciens .xmp pour ne pas se retrouver avec un message d'erreur d'ouverture.

[teddyloup]

Personnellement je n'y tiens pas forcement beaucoup non plus.

Dans un autre domaine, en ce moment je reprend des cartes SIG faites il y a dix ans. Pour certaines d'entre elles il n'y a pas de MAJ d'info particulière mais je les refait quant même pour apporter de la clareté et une cohérence esthétique d'ensemble.

Quant je me repenche sur une photo faite il y a deux ou trois ans c'est généralement parce qu'il s'agit d'une photo qui me plaît et que je souhaite améliorer avec de nouvelles compétences acquises entre-temps. Et il est vrai que je repart souvent de zéro. Par contre, là ou je nuancerais mes propos, c'est que j'aime bien aussi pouvoir comparer ancienne version et nouvelle. Même si je fais un nouveau développement à l’aveugle, sans me soucier des premières versions, à la fin je compare quant même. Parfois on récupère une idée qui marchait mieux avant. Par contre, s'agissant de quelques images, que j'aime particulièrement, j'ai souvent un export jpg et c'est souvent l'export que je compare avant et après.

Je suppose qu'un photographe qui vit de sa pratique aura lui d'autres contraintes...

Peut-être une idée pour trouver un compromis. Pourquoi ne pas imaginer de pouvoir gérer plusieurs miniatures pour une image ? À t1 on cré un développement, la table lumineuse nous affiche une miniature correspondante (une version allégée, adaptée au simple affichage écran, stockée dans la BDD de darktable). À t2, deuxième développement, nouveau xmp et nouvelle miniature également. Si perte de compatibilité entre t1 et t2, à défaut de ne pas pouvoir ouvrir le développement de t1 on peut quant même afficher correctement sa miniature. Histoire de pouvoir comparer quant même dans la table lumineuse les différentes versions. Puis pour ne pas gonfler la BDD se serait une fonction optionnelle que l'on utiliserait pour quelques images d'intérêt. Ainsi tout ne serait pas perdu...

[jpg54]

Personnellement je n'y tiens pas forcement beaucoup non plus.

Dans un autre domaine, en ce moment je reprend des cartes SIG faites il y a dix ans. Pour certaines d'entre elles il n'y a pas de MAJ d'info particulière mais je les refait quant même pour apporter de la clareté et une cohérence esthétique d'ensemble.

Quant je me repenche sur une photo faite il y a deux ou trois ans c'est généralement parce qu'il s'agit d'une photo qui me plaît et que je souhaite améliorer avec de nouvelles compétences acquises entre-temps. Et il est vrai que je repart souvent de zéro. Par contre, là ou je nuancerais mes propos, c'est que j'aime bien aussi pouvoir comparer ancienne version et nouvelle. Même si je fais un nouveau développement à l’aveugle, sans me soucier des premières versions, à la fin je compare quant même. Parfois on récupère une idée qui marchait mieux avant. Par contre, s'agissant de quelques images, que j'aime particulièrement, j'ai souvent un export jpg et c'est souvent l'export que je compare avant et après.

Je suppose qu'un photographe qui vit de sa pratique aura lui d'autres contraintes...

Peut-être une idée pour trouver un compromis. Pourquoi ne pas imaginer de pouvoir gérer plusieurs miniatures pour une image ? À t1 on cré un développement, la table lumineuse nous affiche une miniature correspondante (une version allégée, adaptée au simple affichage écran, stockée dans la BDD de darktable). À t2, deuxième développement, nouveau xmp et nouvelle miniature également. Si perte de compatibilité entre t1 et t2, à défaut de ne pas pouvoir ouvrir le développement de t1 on peut quant même afficher correctement sa miniature.  Histoire de pouvoir comparer quant même dans la table lumineuse les différentes versions. Puis pour ne pas gonfler la BDD se serait une fonction optionnelle que l'on utiliserait pour quelques images d'intérêt. Ainsi tout ne serait pas perdu...

Je pense aussi que de pouvoir garder les anciens .xmp en les mettant en bak permettrait de faire des comparaisons directes
avec l'ajout de la nouvelle fonction de gestion directe des clones dans la table lumineuse mais nécessiterait de garder tous les modules devenus obsolètes.
Un possibilité de comparaison avec les anciens traitements exportés en JPeg : faire un instantané et ensuite ouvrir le nouveau JPeg pour comparer.

[pascal]

Pour moi c'est assez important. Lors de la préparation d'exposition je parcours mes images pour trouver des photos sur un thème. Parfois je remonte une photo qui a quelques années. Et devoir refaire le traitement ce serait une belle perte de temps.

Maintenant on parle de quelle compatibilité?

Pixel-pour-pixel? Pas certain que cela soit très utile de moment ou la photo reste "propre". Mais je veux pouvoir lire mes anciennes images avec les développements appliqués "correctement".

Je pense effectivement que pour les pros c'est souvent différents. On a un contrat, on propose les images et on passe à autre chose. Dans le cadre de photographe exposant ce n'est pas la même donne.

My 2 cents

---

Maintenant, c'est clair que je n'ai pas envie de lancer ce débat avec les devs historiques, j'ai d'autres combats

[jpverrue]

Perso, je fais des expos, comme Pascal, mais aussi du travail pro.

Pour une expo, si je ressort une ancienne photo, en général, je refais le traitement pour les diverses raisons déjà évoquées : amélioration des performances du logiciel, et amélioration de mon expérience et de ma pratique. Cependant, pouvoir comparer l'ancien et le nouveau est un vrai plus. Là aussi pour plusieurs raisons, mais en particulier, parce que si l'on a retenu une photo, c'est qu'elle nous plaît pour son contenu, sa compo, sa lumière, mais aussi son traitement. Aussi, pouvoir revoir et comparer l'ancien traitement et le nouveau - quelque soit la méthode -, me semble important.

Pour du travail pro, c'est autre chose. Chaque fois que j'ai du revenir sur d'anciennes photos, c'est parce que des fichiers d'export avaient été perdus par le client. Or, une fois les photos livrées, je ne garde pas les jpegs, ça prend trop de place. Je dois donc ré-exporter et renvoyer les fichiers. Dans ce cas, il ne faut pas toucher au traitement ; pour deux raisons : ne pas perdre de temps évidemment, mais surtout re-livrer des photos strictement identiques à celles qui avaient été livrées à l'origine pour qu'il n'y aie pas de contestation possible

C'était mon point de vue à moi...

[pepette]

Pour répondre à tes questions, pour moi, garder la compatibilité est peu important, je n'ai pas beaucoup de raw en stock. Tous les raws qui m'intéressent sont déjà convertis en jpeg.
Ce ne sont que des photos de vacances, donc pas de contraintes, ni professionnelles, ni associatives ou autre
J'ai une bd assez légère aussi.
J'ai pris l'habitude (déjà ! grgr) de supprimer de la bd, les "dossiers" traités, mon ordi étant trop léger.
Donc, si besoin, je réimporte un dossier, un fichier. Le catalogage est donc pour l'instant pas important, même si je passe du temps à taguer et que je me suis déjà fait qq règles.

Alors, évidemment, je suis à fond pour une V3.0.0 de dt.

Je prends maintenant ma casquette de développeuse ( php avec framework symfony). On peut faire le parallèle "développeur dt" et "développeur php avec symfony". Tout comme pour dt, je ne connais pas (n'ai pas à connaitre) le code "profond" de symfony.

Je suis confrontée régulièrement à cette question "upgrade or not upgrade".
Dans ce framework, chaque nouvelle version majeure est accompagnée de versions mineures permettant de préparer la migration.
Avant de passer à la 3.0.0, les version 2.8.X, en plus des nouveautés, corrections, nous informe des futures fonctionnalités dépréciées, ce qui nous permet, soit de préparer en douceur la migration, soit de se dire tout simplement : je ne migrerai pas, trop de taf !

Est-il envisageable d'avoir une telle fonctionnalité dans une version 2.6.x ou 2.8.x de dt ?
par exemple :
- en ajoutant une surimpression dans la table lumineuse ou un css spécifique pour les images concernées
- en ajoutant des tags dans la catégorie darktable : version, migration (possible, pas possible ou autre)
Cela permettrait d'évaluer/préparer avant de migrer en filtrant les fichiers concernés en fonction de ses besoins (notes, tags ou autre + tag dt de migration)

Je trouve aussi l'idée des clones très intéressante.
Pour toutes les photos qui "ne passent pas" ou partiellement, créer un clone de "version" peut-être avec une numérotation spécifique correspondant à la version de dt + numérotation du clone, si besoin.

Je crois me souvenir que quelqu'un avait fait le parallèle avec python et la possibilité d'avoir plusieurs versions d'installées et de choisir laquelle utiliser. C'est peu-être trop compliqué pour dt ?

Je sais que cela rajoute du taf et que vous en faites déjà beaucoup.
Brider des devs bénévoles, c'est pas bon non plus.

Aurélien, tu comptes reprendre vraiment beaucoup de modules et donc n'avoir aucune compatibilité ?
Est-il possible d'avoir une version de dt ou plutôt un script juste pour faire l'inventaire de ce qui ne sera pas compatible pour aider les personnes concernées à faire un choix ?
(pour le script, je peux aider, pour le c, trop dur pour moi)

[smartraph]

Bonjour,
très simplement pour ma part, aucun intérêt pour la compatibilité avec les versions précédentes, pour les mêmes raisons évoquées. Après, cette compatibilité peut se comprendre pour les utilisateurs de longue date de Darktable.
Ensuite sur le problème d'être "obligé de trimballer du code à moitié fonctionnel depuis parfois longtemps", je ne mesure pas à quel point c'est un boulet dans l'évolution du logiciel et le confort des développeurs actifs (essentiel puisque c'est grâce à eux que ce logiciel semble évoluer dans le bon sens).