dt 3.7.0~git et exifs

J’ai un problème depuis environ un ou deux mois avec la version 3.7 Master.

Tout se passe bien dans DT. Mais quand j’ouvre mes images pour les trier, renommer, etc avec Gthumb il plante.

J’ai en premier pensé à un problème Gthumb ou librairie exif car quand je supprime le support exif dans Gthumb plus de problème mais impossible de trier et renommer en fonction des exifs.

J’ai remarqué que des jpg ne venant pas de DT fonctionne très bien dans Gthumb avec les exifs.

J’ai donc installé Rawtherapee pour tester mes raw j’ai exporté mes raw avec rawtherapee et là aucun problème dans Gthumb (mais je ne veux pas travailler avec rawtherapee).

Il y a donc bien un problème pour Gthumb avec les exifs des fichiers jpg qui sortent de DT.

J’ai regardé toutes les options liées aux exifs, j’ai changé plusieurs réglages dans dt comme ne pas ajouter l’historique, ne pas ajouter de mots clefs, mais rien à faire à chaque fois les jpg sortis de DT font planter Gthumb.

Avez-vous une idée d’où cela peu venir une piste pour trouver une solution car Gthumb est pour moi un outil indispensable.

Bonjour Luc, je viens de tester quelques photos de mon Gx8 développées avec les dernières versions de darktable master. Elles sont ouvertes sans problème.

je peux t’envoyer deux jpg pour que tu testes si c’est mon GThumb ou mon darktable?
Voir si mes jpg font planter ton Gthumb?
Tu as bien activé l’extension Gthumb pour exploiter les exifs?
[hr]
Tu peux télécharger les jpg ici:
http://luc.lucnix.be/03-Cigar-Lounge-33-09-2021.jpg

http://luc.lucnix.be/02-Cigar-Lounge-33-09-2021.jpg

http://luc.lucnix.be/01-Cigar-Lounge-33-09-2021.jpg

Je les télécharge et je les teste. Bien sûr, j’ai l’affichage des exif !

Ça doit-être Gthumb qui pose problème avec les jpg de darktable.
J’ai la version 3.11.2

Quand j’ouvre des jpg plus anciens qui ne posait pas de problème à l’époque Gthumb plante.
C’est donc la dernière version de Gthumb qui ne supporte pas quelque-chose venant de darktable, mais quoi…

Je suis sur Ubuntu 21.04 avec Gthub 3.11.2 et exiv2 (0.27.3-3ubuntu1.5)

Message d’erreur au plantage de Gthumb:
terminate called after throwing an instance of ‹ std::out_of_range ›
what(): basic_string::at: __n (which is 19) >= this->size() (which is 19)
Abandon (core dumped)

Pas de problème pour ouvrir les 3 tofs :

avec :

Je suis sous OpenSuse Tumbleweed (une rolling release) et KDE.
[hr]
Voilà la dernière version de GThumb qui est installée sur mon système :

lien pour partager des photos

C’est donc bien l’update Gthumb 3.11 qui posse problème avec DT.

Si quelqu’un à la version 3.11 de Gthumb je veux bien un test pour être certain que ce n’est pas chez moi qu’il y a un problème.

Je vais rechercher un .deb plus ancien de Gthumb pour voir…

J’ai rencontré un pb similaire sur Mageia avec gwenview.
La cause en étaient les fichiers jpg générés avec DT , et la faute était finalement dans lib64exiv2
Le bug report Mageia au cas où ça peut aider:
https://bugs.mageia.org/show_bug.cgi?id=29440

Cela semble bien lié à exiv2 qui a eu une mise à jour environ au moment ou j’ai eu le problème.
Je viens de tester sur une Ubuntu 20.04 aucun problème mais c’est une version plus ancienne de exiv2 et Gthumb.

Par contre pourquoi le problème n’arrive qu’avec les jpg venant de darktable et pas les autres là aucune idée.

Le pourquoi, je ne sais pas.
Pas contre, j’avais juste enlevé le package lib64exiv2 à jour et remis le précédent en attendant la solution, et ça refonctionnait sans soucis.

je suis passé en version Ubuntu 21.10 mais le problème est toujours présent et ce uniquement avec les jpg venant de darktable.

Il y a un rapport de bug mais rien ne bouge. Alors je sais pas si c’est darktable ou Gthumb ou exiv2 mais c’est vraiment casse pied…
https://bugs.launchpad.net/ubuntu/+source/gthumb/+bug/1943586

Oui, ce n’est pas un problème de DarkTable mais lib64exiv2; cette librairie a été mise à jour pour ma distrib (Mageia 8) et plus de problème. Voir les packageurs Ubuntu pour leur demander la mise à jour pour lib64exiv2.

Hello,
Je confirme le pb sur le couple fichier jpeg généré par dt et lecture par libexiv2 Ubuntu (gwenview) depuis fin Aout 21.Version 0.27.2-ubuntu2.6(focal-updates)
Je suis revenu à la version antérieure(focal) en attendant une version corrigée de exiv2 sur Ubuntu.
Cordialement.

Je viens de regarder ce que j’ai sous OpenSuse Tumbleweed :

S | Name | Type | Version | Arch | Repository ---+-------------------------+--------+-------------+--------------+---------------------- i+ | exiv2 | paquet | 0.27.4-1.2 | x86_64 | Dépôt principal (OSS) i+ | exiv2 | paquet | 0.27.4-1.2 | x86_64 | openSUSE-20210920-0 v | exiv2 | paquet | 0.27.4-1.2 | i586 | Dépôt principal (OSS) v | exiv2 | paquet | 0.27.4-1.2 | i586 | openSUSE-20210920-0 i+ | exiv2-lang | paquet | 0.27.4-1.2 | noarch | Dépôt principal (OSS) i+ | exiv2-lang | paquet | 0.27.4-1.2 | noarch | openSUSE-20210920-0 i+ | libKF5KExiv2-15_0_0 | paquet | 21.08.3-1.1 | x86_64 | Dépôt principal (OSS) i+ | libKF5KExiv2-15_0_0 | paquet | 21.08.3-1.1 | x86_64 | openSUSE-20210920-0 v | libKF5KExiv2-15_0_0 | paquet | 21.08.3-1.1 | i586 | Dépôt principal (OSS) v | libKF5KExiv2-15_0_0 | paquet | 21.08.3-1.1 | i586 | openSUSE-20210920-0 i+ | libexiv2-27 | paquet | 0.27.4-1.2 | x86_64 | Dépôt principal (OSS) i+ | libexiv2-27 | paquet | 0.27.4-1.2 | x86_64 | openSUSE-20210920-0 v | libexiv2-27 | paquet | 0.27.4-1.2 | i586 | Dépôt principal (OSS) v | libexiv2-27 | paquet | 0.27.4-1.2 | i586 | openSUSE-20210920-0 | libexiv2-27-32bit | paquet | 0.27.4-1.2 | x86_64 | Dépôt principal (OSS) | libexiv2-27-32bit | paquet | 0.27.4-1.2 | x86_64 | openSUSE-20210920-0 i+ | libexiv2-devel | paquet | 0.27.4-1.2 | x86_64 | Dépôt principal (OSS) i+ | libexiv2-devel | paquet | 0.27.4-1.2 | x86_64 | openSUSE-20210920-0 v | libexiv2-devel | paquet | 0.27.4-1.2 | i586 | Dépôt principal (OSS) v | libexiv2-devel | paquet | 0.27.4-1.2 | i586 | openSUSE-20210920-0 i+ | libexiv2-xmp-static | paquet | 0.27.4-1.2 | x86_64 | Dépôt principal (OSS) i+ | libexiv2-xmp-static | paquet | 0.27.4-1.2 | x86_64 | openSUSE-20210920-0 v | libexiv2-xmp-static | paquet | 0.27.4-1.2 | i586 | Dépôt principal (OSS) v | libexiv2-xmp-static | paquet | 0.27.4-1.2 | i586 | openSUSE-20210920-0 i+ | libgexiv2-2 | paquet | 0.14.0-1.1 | x86_64 | Dépôt principal (OSS) i+ | libgexiv2-2 | paquet | 0.14.0-1.1 | x86_64 | openSUSE-20210920-0 v | libgexiv2-2 | paquet | 0.14.0-1.1 | i586 | Dépôt principal (OSS) v | libgexiv2-2 | paquet | 0.14.0-1.1 | i586 | openSUSE-20210920-0 | libgexiv2-2-32bit | paquet | 0.14.0-1.1 | x86_64 | Dépôt principal (OSS) | libgexiv2-2-32bit | paquet | 0.14.0-1.1 | x86_64 | openSUSE-20210920-0 | libgexiv2-devel | paquet | 0.14.0-1.1 | x86_64 | Dépôt principal (OSS) | libgexiv2-devel | paquet | 0.14.0-1.1 | x86_64 | openSUSE-20210920-0 | libgexiv2-devel | paquet | 0.14.0-1.1 | i586 | Dépôt principal (OSS) | libgexiv2-devel | paquet | 0.14.0-1.1 | i586 | openSUSE-20210920-0 | libkexiv2-devel | paquet | 21.08.3-1.1 | x86_64 | Dépôt principal (OSS) | libkexiv2-devel | paquet | 21.08.3-1.1 | x86_64 | openSUSE-20210920-0 | libkexiv2-devel | paquet | 21.08.3-1.1 | i586 | Dépôt principal (OSS) | libkexiv2-devel | paquet | 21.08.3-1.1 | i586 | openSUSE-20210920-0 | python3-gexiv2 | paquet | 0.14.0-1.1 | x86_64 | Dépôt principal (OSS) | python3-gexiv2 | paquet | 0.14.0-1.1 | x86_64 | openSUSE-20210920-0 | python3-gexiv2 | paquet | 0.14.0-1.1 | i586 | Dépôt principal (OSS) | python3-gexiv2 | paquet | 0.14.0-1.1 | i586 | openSUSE-20210920-0 | python36-exiv2 | paquet | 0.9.3-1.3 | x86_64 | Dépôt principal (OSS) | python36-exiv2 | paquet | 0.9.3-1.3 | x86_64 | openSUSE-20210920-0 | python36-exiv2 | paquet | 0.9.3-1.3 | i586 | Dépôt principal (OSS) | python36-exiv2 | paquet | 0.9.3-1.3 | i586 | openSUSE-20210920-0 | python38-exiv2 | paquet | 0.9.3-1.3 | x86_64 | Dépôt principal (OSS) | python38-exiv2 | paquet | 0.9.3-1.3 | x86_64 | openSUSE-20210920-0 | python38-exiv2 | paquet | 0.9.3-1.3 | i586 | Dépôt principal (OSS) | python38-exiv2 | paquet | 0.9.3-1.3 | i586 | openSUSE-20210920-0 | python39-exiv2 | paquet | 0.9.3-1.3 | x86_64 | Dépôt principal (OSS) | python39-exiv2 | paquet | 0.9.3-1.3 | x86_64 | openSUSE-20210920-0 | python39-exiv2 | paquet | 0.9.3-1.3 | i586 | Dépôt principal (OSS) | python39-exiv2 | paquet | 0.9.3-1.3 | i586 | openSUSE-20210920-0 i+ | typelib-1_0-GExiv2-0_10 | paquet | 0.14.0-1.1 | x86_64 | Dépôt principal (OSS) i+ | typelib-1_0-GExiv2-0_10 | paquet | 0.14.0-1.1 | x86_64 | openSUSE-20210920-0 v | typelib-1_0-GExiv2-0_10 | paquet | 0.14.0-1.1 | i586 | Dépôt principal (OSS) v | typelib-1_0-GExiv2-0_10 | paquet | 0.14.0-1.1 | i586 | openSUSE-20210920-0
Je n’ai pas de problème d’affichage avec d’affichage des JPeg dans GThulb. Ce qui est utilisé est précédé d’un i+

Bonjour,

Sur KDE neon user edition, je viens d’installer gthumb pour tester le problème de Luc.
Les raw venant de DT s’affichent bien.
Par contre ma visionneuse gwenview, depuis plus d’un mois, affiche tous les raw en pixelisant à mort.
J’ai fait un rapport de bug…
Du coup, j’ai installé nomacs qui est impeccable.
Mais gwenview me manque.

Ben pourquoi ne pas utiliser une distrib bien francisée depuis ses origines, et où les développeurs sont réactifs dès qu’on signale une pb?
Bref, la Mageia, et gwenview fonctionne du tonnerre :wink:

Sous OpenSuse Tumbleweed, GWenView et GThumb fonctionne parfaitement pour l’affichage des Raw et des JPeg. C’est une Rolling Release allemande qui a développée KDE.

Vu mon avatar, je dois essayer Opensuse :wink:

J’ai pas pu interprété ton pseudo. Je te conseille vraiment la version Tumbleweed en KDE, c’est la meilleur intégration de KDE que j’ai utilisée. On est 2 à pouvoir t’aider ici à le maîtriser.

Merci, c’est noté.