Version 1.9

La version 1.9 vient de sortir. Vous pouvez télécharger ici : agriggio / ART / Downloads — Bitbucket

Pour des builds W10 optimisés pour certaines architectures
https://keybase.pub/gaaned92/ART-W64NightlyBuilds/

New release, 1.9. Changes:

New gradient mask, thanks to @Hombre
Updated the CR3 decoder to the latest from libraw
Added option to periodically auto-save arp sidecars
Slightly reworked the UI of the Log Tone Mapping tool
A bunch of bug fixes
2 « J'aime »

Merci @edmond_Gautier, je vais compiler cette version :art:

Oui, je l’ai compilée hier.

Bonjour à tous,

Traduit via Gougueule, l’annonce concernant la version 1.9 donne ça en français :

"Nouveau masque dégradé, grâce à @Hombre
Mise à jour du décodeur CR3 avec la dernière version de libraw
Ajout d’une option pour enregistrer automatiquement les sidecars arp périodiquement
Légèrement retravaillé l’interface utilisateur de l’outil Log Tone Mapping
Un tas de corrections de bogues "

Or je me demande bien ce que sont les “sidicars arp”…
Cela a rapport avec l’historique ?

les fichiers .ARP sont des fichiers sidecars

De Wikipedia anglais

Sidecar files, also known as buddy files or connected files, are computer files that store data (often metadata) which is not supported by the format of a source file.

There may be one or more sidecar files for each source file. There may also be “metadata databases” where one database contains metadata for several source files.

In most cases the relationship between the source file and the sidecar file is based on the file name; sidecar files have the same base name as the source file, but with a different extension. The problem with this system is that most operating systems and file managers have no knowledge of these relationships, and might allow the user to rename or move one of the files thereby breaking the relationship.

Traduction

Les fichiers Sidecar, également appelés fichiers connectés, sont des fichiers informatiques qui stockent des données (souvent des métadonnées) qui ne sont pas prises en charge par le format d’un fichier source. Il peut y avoir un ou plusieurs fichiers side-car pour chaque fichier source. Il peut également y avoir des «bases de données de métadonnées» où une base de données contient des métadonnées pour plusieurs fichiers source.
Dans la plupart des cas, la relation entre le fichier source et le fichier side-car est basée sur le nom du fichier; Les fichiers side-car ont le même nom de base que le fichier source, mais avec une extension différente. Le problème avec ce système est que la plupart des systèmes d’exploitation et des gestionnaires de fichiers n’ont aucune connaissance de ces relations et peuvent permettre à l’utilisateur de renommer ou de déplacer l’un des fichiers, rompant ainsi la relation.

super merci,

Merci Edmond pour ces explications.
La mise à jour ne change rien au fait que l’on perde l’historique du développement à la fermeture de ART, donc ?

Merci :+1:

On avait eu déjà des discussions ici à ce sujet. Je n’ai pas eu le courage ni le temps d’utiliser beaucoup darktable (bien que depuis j’ai réalisé des builds W10) et donc je n’ai pas progressé dans la compréhension de l’utilité de l’historique et de son apport dans ART. Mais je ne conteste pas qu’il puisse être utile ou même indispensable pour certains.

Je ne me sens donc pas en mesure d’aller faire une demande à Alberto en lui présentant des cas d’utilisation précis et en lui démontrant que les fonctions existantes de ART ne permettent pas de réaliser la même chose. Sinon je connais sa réponse, car il y a déjà eu des demandes à ce sujet !

Il y a peut-être quelqu’un qui pourrait prendre en charge cette demande.
Peut-être aussi une petite vidéo illustrant comment l’historique est utilisé et ce que cela apporte d’efficacité par rapport aux instantanés de ARP pourrait débloquer la situation.

Je ne vois pas non plus l’intérêt réel de l’historique… sur Darktable à l’époque (assez lointaine) ou je l’utilisais, l’ordre du pipe dans le traitement était très important et changer cet ordre pouvait vraiment modifier considérablement la photo… Je ne sais pas si c’est toujours le cas avec les changements de Dt…
Mais il me semble (du moins je n’ai pas remarqué) que dans Art, l’ordre du traitement n’affecte pas considérablement l’effet obtenu sur l’image… l’historique pour reprendre un traitement n’est du coup pas important… la modification des curseurs dans les modules peut se faire dans n’importe quel ordre…

moi j’utilise les instantané, j’en fais plusieurs , lors du traitement, et je peux revenir facilement à un niveau de traitement antérieur si cela ne me convient pas

Dans ART, l’ordre des traitements est fixe et défini ici : agriggio / ART / wiki / Pipeline — Bitbucket
donc ta remarque

est vraie.

L’historique de darktable ne permet pas de changer l’ordre des modules, ça se fait dans l’onglet “modules actifs”, bien que cette possibilité soit offert, je ne l’ai jamais utilisé et je le déconseille. L’historique présente l’ordre d’utilisation des modules (un module peut être présent dans l’historique) et son gros avantage, c’est de le voir lorsque l’on ré-affiche après fermeture ou pour voir le traitement lorsque l’on reçois une photo accompagnée du .xmp.

l’ordre d’utilisation par l’utilisateur ou l’ordre dans le pipeline de DT?

Donc si je comprends, c’est un texte en clair affiché sur l’écran qui liste les modules utilisés dans un ordre donné.
Donc l’avantage est que ça évite d’ouvrir les différents onglets pour identifier les modules activés.

Voir à tout moment la liste des modules activés dans l’ordre du pipeline est une synthèse intéressante du traitement effectué.

L’affichage dans l’ordre d’activation des modules par l’utilisateur pourrait permettre de comprendre la démarche d’un autre utilisateur pour réaliser un traitement. Mais c’est plus compliqué, car souvent on revient sur des réglages ou on élimine des modules qui s’avèrent inutiles. Mais je ne suis pas du tout intéressé par ça. Je préfère regarder des tutos.

Juste pour rappel, le pipeline est important ou pas selon le bout par lequel on le prends. L’ordre de traitement des modules (pipeline) est gravé en dur et donc a de facto son importance dans certains cas. Le plus parlant est bien sûr [ le traitement du bruit/utilisation des ressources système ] qui aura un impact dans le ralentissement de la machine. Un autre exemple est la position dans le pipeline du profil d’entrée ou de sortie ou plus généralement la saturation qui peut poser problème sur certains modules. Je note d’ailleurs qu’Alberto a par exemple rajouter des curseurs de satu dans le module correction des couleurs comme il en existe d’ailleurs dans dt.

Après, le rapport entre l’ordre dans lequel on le fait et ce que l’on voit à l’écran est souvent si peu évident que je peux aisément comprendre vos déclarations…

L’historique donne l’ordre du traitement. Ce serait intéressant d’avoir un item (n° par exemple) qui indiquerait la position de l’action dans l’ordre du pipeline. Je l’avais demandé à Alberto mais il avait estimé que ce n’était pas nécessaire. En celà, les instantanés sont un bon compromis à tout ça

Rien, à voir, mais sur la dernière version on peut modifier certain paramètre de conf , voir ici : Browser speed/performance - Software / ART - discuss.pixls.us

Oui, l’ordre d’utilisation par l’utilisateur.

Oui, l’historique peut être compressé et là ne reste que les derniers modules ouverts, idem pour la récupération d’un traitement avec un .xmp.

Tout à fait, c’est très pratique surtout pour aider un utilisateur sur un traitement s’il te donne le .xmp et tu peux lui fournir le tien ou il peut voir tes étapes sans avoir à ouvrir les onglets pour trouver les modules utilisés.

Je viens d’ouvrir un photo déjà traitée :


et le passage de la souris sur une étape du traitement me montre les valeurs du module :

Sortie d’une sous version 1.9.1 corrigeant quelques bugs.