Correction d'objectif : pas de reconnaissance auto du boîtier

Je pense que pour lever le doute, il faudrait repartir de zéro :slight_smile:

  • copier les photos incriminées dans un répertoire sans les ARP
  • changer le nom du répertoire config par exemple, art-dev en art-dev$
  • Redémarrer ART et tester les photos incriminées. Un nouveau répertoire config va être créé.

J’ai essayé avec d’autres boîtiers que des µ4/3 : même problème.

1 « J'aime »

J’ai pris 4 RAW dans un répertoire sans les fichiers .arp (Canon ; Pentax et les 2 Lumix). J’ai renommé mon répertoire config : j’ai toujours le même problème.
Je viens d’essayer avec RawTherapee : la mise à jour de la correction d’objectifs se fait correctement sauf pour celle du Pentax que je dois faire manuellement.

1 « J'aime »

J’ai déjà fait cette manip, même problème.

En faisant sous Windows la manip décrite plus haut et en s’assurant que %PATH% ne contient pas d’accès à des répertoires contenant des dll d’application , je ne comprends pas pourquoi ça marcherait chez moi et pas chez toi.

Apres il faut peut-être soumettre le problème à Alberto.

Non, je n’ai pas fait la manip sous W10. Je l’ai fait sous Linux.

Ne connaissant pas bien Linux ni ses innombrables distributions, j’ai une question à vous poser.
Pour faire tourner une application, vous téléchargez un paquet depuis un dépôt de la distribution que vous installez. Ce logiciel nécessite des dépendances. Certaines sont déjà présentes dans le système, d’autres doivent être téléchargées en même temps que l’appli. Enfin certaines dépendances seront mises à jour pour les besoins d’une autre appli.

Comment vous assurez-vous que l’appli (ART par exemple) est compatible à un instant donné, avec la version de chacune ses dépendances présente dans le système ?

Hors sujet à dépllcer plutôt dans bla bla ?
La gestion des dépendances sous linux est quasi-parfaite et transparente depuis très longtemps, en ce qui concerne les principales distributions qui les gèrent en pratique, compte-tenu de ce que tu as déjà sur ta machine. Rien de comparable avec l’OS à fenêtres. En pratique, tu ne t’en occupes jamais si tu as accepté leur installation simultanée de celle du logiciel. Les mises-à-jour du logiciel te demandent simplement d’accepter l’installation des éventuelles nouvelles dépendances, mais ne suppriment pas celles utilisées par d’autres logiciels
À part sont les appimage ou les flatpak, paquets intégrants de manière immuable les dépendances nécessaires.
Les compilations demandent l’installation manuelle préalable de bibliothèques.

1 « J'aime »

Tout à fait d’accord avec Guy. Avec Linux, nous n’avons pas de liens symboliques comme “%PATH%” ! Je compile depuis pratiquement depuis mes débuts sous Linux, j’ai donné les démarches sur le forumlumix.com de RawTherapee et de darktable.

1 « J'aime »

Pas si hors sujet. Je cherche une raison du non-fonctionnement de lensfun. Si aucune erreur ne peut se glisser dans la gestion de conf, c’est donc d’après vous une fausse piste.

Voilà la variable %PATH% :

Je suis toujours sur mon problème. J’avais l’espoir que les choses rentrent dans l’ordre avec la nouvelle version ART 1.18 qui vient de sortir, mais ce n’est pas le cas.
Hier, j’ai eu la “chance” de croiser un Windows 11 sur lequel je me suis empressé d’installer ART ; la reconnaissance automatique des boîtiers et des objectifs y fonctionne parfaitement. C’est d’autant plus frustrant.
Il faudrait que j’essaie une autre distribution pour voir. Il me faut trouver le courage de m’y atteler.

Itou, pour mon problème avec la version 1.18.0 !

Nouvelle année… Et tout rentre dans l’ordre !

Je m’étais donc promis d’essayer une autre distribution et j’ai fini par me prendre par la main en profitant d’un portable à réinstaller. Bon… N’exagérons rien ! Je garde la Mint, mon courage a des limites, mais j’installe XFCE à la place de Cinnamon. Quelle aventure, n’est-ce pas ?
Je télécharge le binaire 1.18.0 ; il ne veut pas démarrer (même symptôme que cedbarret dans ce fil. Pas le temps de me pencher sur le problème. Je vais chercher la dernière AppImage connue, 1.16.4. Miracle, ils sont tous là, bien rangés par ordre alphabétique et reconnus automatiquement : GX8, G9, 100-400, etc.
OK ! Transfert de l’appimage sur la machine de bureau… Effacement des fichiers arp… Ça ne marche pas ! Je retrouve mon problème de départ intacte. Est-ce que ART trouve la cannelle indigeste ? Pas possible. Dossier de config ? L’appImage utilise le même dossier que le binaire, donc suppression pour la enIéme fois… Relance…
OK ! Sans trop y croire, je relance le binaire en étant persuadé qu’il va me “refoutre le boxon”, mais non : GX8, G9, 100-400, etc, présents en bon ordre, y compris dans les répertoires dans lequel je n’avais pas effacer les arp.

Conclusion : cela venait bien d’une erreur inscrite dans un fichier de config, mais pourquoi cette erreur se reconduisait-elle à chaque effacement de ces fichiers ? Et comment l’appimage a forcé la configuration dans le bon sens ? Est-ce qu’il y aurait une très vieille version de lensfun qui traînerait sur ma machine ? Sans doute mais, j’ai beau chercher, elle reste introuvable.

En attendant, je vais poursuivre sans frustration particulière mon “apprentissage” de ART. Merci à ceux qui ont tenté de m’aider.

Je viens d’essayer avec ART.appimage, il ne se lance pas sous OpenSuse Tumbelweed :

J’ai relu les symptômes que tu décris dans ton premier message et, effectivement, on peut voir que le boîtier et l’objectif ne s’affichent pas immédiatement dans les listes déroulantes lorsqu’on est en détection automatique. Par contre, j’ai remarqué que la détection automatique se faisait quand même correctement.
Si tu fais un simple aller-retour, auto → manuel → auto, tu peux te rendre compte que l’affichage manuel se met à jour tout seul.

Effectivement, ça fonctionne, c’est quand même bizarre comme comportement que l’on n’a pas dans RT. Merci d’avoir confirmé ce comportement, je commençais à me prendre pour un extraterrestre. Je pense qu’il faudrait remonter à Agriggio et que ce fonctionnement ne se produit chez tout le monde.

C’est peut-être spécifique à la monture MFT. Je ne peux pas le vérifier car je n’ai plus rien d’autre qui me permettrait de comparer.

J’ai pas mal de RAW de différents boîtiers passés par des utilisateurs pour les aider ou télécharger sur DPReview (pour les nouveaux boîtiers), chez moi ça se produit aussi bien avec des Canon, FujiFilm, Nikon et Sony !

Comme jpg54 parlait de Fujifilm et que j’ai du Fujifilm j’ai essayé de voir si le comportement était bon ou pas de mon coté (sur une Manjaro Linux et ART 1.18.1 compilé)
Pas de problème de mon coté, voire comme jpg54 j’ai aussi d’autres images d’utilisateurs divers avec divers matériels, et tout semble bien fonctionner.

Par contre sur tes captures écran, jpg54, tu ouvres avec le dernier profil sauvegardé et le bouton radio actif pour le traitement des objectifs est celui “Automatique d’après la base de données”.
Les renseignements pour le bouton “Manuel d’après la base de données” sont ceux… du profil d’avant… assez logique si l’on considère que les renseignements boîtier/objectif ne concerne que ce bouton radio “Manuel”, non ?

J’ai aussi ce comportement, mais si j’active le bouton devant manuel il me trouve le bon couple boîtier/objectif.

Même comportement sous ma session Win 10, exemple ici où le couple boîtier/objectif est celui de l’image du papillon, alors que l’image active n’a rien à voir.