27-01-19, 15:16
darktable a été conçu de façon modulaire (et le fait d’enlever un module ne va pas affecter les autres modules sauf que tous les .xmp qui l'utilisent ne pourrons plus être ouverts.
Compatibilité : à quel point ça sert ?
|
27-01-19, 15:16
darktable a été conçu de façon modulaire (et le fait d’enlever un module ne va pas affecter les autres modules sauf que tous les .xmp qui l'utilisent ne pourrons plus être ouverts.
27-01-19, 15:37
Y a-t-il possibilité d'afficher la version de dt qui a été utilisée dans le xmp ?
En gros un xmp de la version 2.6.0 je n'y retoucherais pas, par contre une version antérieure qui n'aurait pas "subi" les dernières nouveautés et améliorations repasserait à la moulinette. Du moins dans ma manière de développer ...
je n'oublie pas que le chêne, avant d'être grand et fort, était comme moi ... un gland !
27-01-19, 16:22
Pour l'instant, il n'y a pas de version de darktable dans le .xmp.
(27-01-19, 12:55)jpverrue a écrit : Perso, je fais des expos, comme Pascal, mais aussi du travail pro.J'ai oublié de préciser que pour ce dernier usage, le délai entre la première exportation et la ré-exportation n'a jamais été très long, six mois, un an tout au plus. (27-01-19, 15:16)jpg54 a écrit : darktable a été conçu de façon modulaire (et le fait d’enlever un module ne va pas affecter les autres modules sauf que tous les .xmp qui l'utilisent ne pourrons plus être ouverts.C'est un peu plus subtil qu'à ça. Si on prend un exemple simple : contraste local ; à l'origine, le module fonctionnait avec un seul type de filtre, le filtre bilatéral, puis avec la version 2.4 un nouveau filtre est apparu, le filtre laplacien. Les deux filtres sont maintenant disponibles dans le module pour deux raisons : bien sur, pour laisser le choix du filtre à l'utilisateur, mais aussi pour garder la compatibilité avec les anciens traitements. Et même si l'ancien filtre devenait complètement obsolète, on ne pourrait pas l'enlever du module compte tenu de la politique actuelle de rétro-compatibilité.
Mes photos : jpverrue.fr
27-01-19, 17:55
> Et même si l'ancien filtre devenait complètement obsolète, on ne pourrait pas l'enlever du module compte tenu de la politique actuelle de rétro-compatibilité.
Un autre bémol alors On ne peut pas l'enlever mais lui donner le statut "obsolète". Dans ce cas il n’apparaît plus pour les nouvelles images, ne peut plus être donc sélectionner mais il reste dans le "pixelpipe" des images l'ayant utilisé.
27-01-19, 18:02
Merci pascal pour le complément d'information. J'ignorais cette possibilité de garder un vieil algo "caché"
Mes photos : jpverrue.fr
@Aurélien: un autre point, pour en avoir déjà discuter avec toi. Si tu parles ici plus de flux interne qui si on le change risque de modifier le résultat final de quelques % (dE 2? 5?) sur les couleurs alors je m'en moque aussi. Si le résultat final est plus "cohérent" alors je suis pour. Comme tout le bruit que le changement du module de recadrage à fait car ça risquait de modifier quelques pixels de l'ordre de 0,01% !!!
Pour être précis ce qui est un grand NON pour moi c'est: - de supprimer un module - de changer un module qui fait qu'une image traitée avec perd tous les réglages et on doit recommencer - de changer un module qui ferait des modifications de plus de 5 dE sur les pixels. Pourquoi 5 ? Avec un dE de 2 on ne voit pas la différence, avec un dE de 5 on est dans l'acceptable. Donc je pense que cette limite de 5 est à garder en tête. Aurélien, es-tu en phase avec ça?
27-01-19, 19:03
Merci pour l'info Pascal, on peut caché un module à partir de l'interface ou c'est à venir ?
27-01-19, 19:15
Non, c'est dans le code. Les devs peuvent déclarer un module IOP_FLAGS_DEPRECATED, une valeur d'un flag retourné par chaque module lors de l'initialisation. Il y a déjà un cas comme l'ancien module equaliser (src/iop/equalizer.c). Le nouvel égaliser que nous connaissons est sous le nom src/iop/atrous.c.
27-01-19, 19:54
Merci Pascal pour les précisions.
|
« Sujet précédent | Sujet suivant »
|