Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 19/06/2018, à 10:50

phidu

Bug de Gimp-ufraw sur Bionic Beaver

Bonjour,

J'utilise Gimp et Ufraw pour développer mes fichier RAW (des ".nef" de Nikon).
Je n'avais aucun soucis jusqu'à Bionic Beaver, ça fonctionnait parfaitement sur différentes distributions (dont Debian Stretch).

Mais depuis Ubuntu 18.04 j'ai ce message de Gimp lors du transfert de l'image entre Ufraw et Gimp:

L'ouverture de « /media/user/cle-usb/photos/photo.NEF » a échoué : La procédure « file-ufraw-load » n'a renvoyé aucune valeur

Le problème est le même sur plusieurs machines, des installations à partir d'iso différentes et persiste après plusieurs mises à jour.

Les paquets installés via synaptic:

gimp
gimp-ufraw
ufraw
gnome-raw-thumbnailer
gnome-xcf-thumbnailer
digikam
kimageformat-plugin


Ufraw seul, fonctionne correctement mais je dois alors passer par l'enregistrement d'un fichier .ppm, puis l'ouvrir dans Gimp, c'est faisable mais rajoute une manipulation, ce qui devient gênant lorsque je traite un nombre conséquent de photos.
Je précise que le comportement de Gimp-ufraw est le même avec ou sans Ufraw installé.

Lors de tests, certains fichiers se sont correctement ouverts (mais un très faible pourcentage), ces fichiers ne présentent pas de différence visible avec ceux qui ne s'ouvrent pas,dans les deux cas ce sont des .NEF venant du même appareil, sur clé usb ou en local.

Je suis surpris par l'absence totale de résultats de rechercher concernant ce problème, je ne crois pas être un cas isolé, la combinaison "nikon-gimp-ufraw-ubuntu" semble être courante et si le problème apparaît sur différentes machines, je ne devrais pas être le seul a y être confronté...

Merci d'avance pour vos suggestions !

Dernière modification par phidu (Le 19/06/2018, à 10:52)

Hors ligne

#2 Le 29/06/2018, à 07:40

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

Peux-tu montrer

df -Th

?

Peux-tu lancer

ufraw un-fichier.NEF

depuis le terminal et montrer, juste après l'incident, le retour complet ?


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#3 Le 29/06/2018, à 08:43

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

Le retour de df -Th:

Sys. de fichiers Type     Taille Utilisé Dispo Uti% Monté sur
udev             devtmpfs   7.8G       0  7.8G   0% /dev
tmpfs            tmpfs      1.6G    2.0M  1.6G   1% /run
/dev/sda1        ext4       234G     16G  207G   7% /
tmpfs            tmpfs      7.8G     30M  7.8G   1% /dev/shm
tmpfs            tmpfs      5.0M    4.0K  5.0M   1% /run/lock
tmpfs            tmpfs      7.8G       0  7.8G   0% /sys/fs/cgroup
/dev/loop3       squashfs    87M     87M     0 100% /snap/core/4650
/dev/loop2       squashfs    87M     87M     0 100% /snap/core/4571
/dev/loop0       squashfs    15M     15M     0 100% /snap/gnome-logs/34
/dev/loop1       squashfs    22M     22M     0 100% /snap/gnome-logs/31
/dev/loop4       squashfs   2.4M    2.4M     0 100% /snap/gnome-calculator/178
/dev/loop5       squashfs    13M     13M     0 100% /snap/gnome-characters/101
/dev/loop6       squashfs   3.8M    3.8M     0 100% /snap/gnome-system-monitor/39
/dev/loop7       squashfs    87M     87M     0 100% /snap/core/4830
/dev/loop8       squashfs   2.4M    2.4M     0 100% /snap/gnome-calculator/167
/dev/loop9       squashfs   4.8M    4.8M     0 100% /snap/htop/381
/dev/loop10      squashfs   3.8M    3.8M     0 100% /snap/gnome-system-monitor/41
/dev/loop11      squashfs    15M     15M     0 100% /snap/gnome-logs/37
/dev/loop12      squashfs   2.4M    2.4M     0 100% /snap/gnome-calculator/170
/dev/loop13      squashfs   4.8M    4.8M     0 100% /snap/htop/224
/dev/loop14      squashfs   140M    140M     0 100% /snap/gnome-3-26-1604/64
/dev/loop15      squashfs   512K    512K     0 100% /snap/htop/191
/dev/loop16      squashfs   141M    141M     0 100% /snap/gnome-3-26-1604/59
/dev/loop18      squashfs   141M    141M     0 100% /snap/gnome-3-26-1604/62
/dev/loop17      squashfs   3.8M    3.8M     0 100% /snap/gnome-system-monitor/45
/dev/loop19      squashfs    13M     13M     0 100% /snap/gnome-characters/86
/dev/loop20      squashfs    13M     13M     0 100% /snap/gnome-characters/96
tmpfs            tmpfs      1.6G     20K  1.6G   1% /run/user/120
tmpfs            tmpfs      1.6G     40K  1.6G   1% /run/user/1001
/dev/sdb         ext4       917G    668G  203G  77% /media/phidu/PHDKSAUV-1
/dev/sdc1        vfat       232G    199G   34G  86% /media/phidu/PHDK256-2

L'ouverture d'un fichier .NEF dans ufraw ne retourne aucun messages d'erreur dans le terminal, par contre, au moment ou je demande à ufraw d'ouvrir le résultat dans Gimp:

(ufraw:2318): GLib-GObject-CRITICAL **: 07:28:51.577: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(ufraw:2318): GLib-GObject-CRITICAL **: 07:28:51.578: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(gimp:2331): GLib-GObject-WARNING **: 07:28:51.757: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size'

(gimp:2331): Gimp-Widgets-CRITICAL **: 07:28:52.195: gimp_device_info_set_device: assertion '(info->device == NULL && GDK_IS_DEVICE (device)) || (GDK_IS_DEVICE (info->device) && device == NULL)' failed
Erreur de segmentation (core dumped)

puis, promt suivant:

/usr/lib/gimp/2.0/plug-ins/ufraw-gimp: fatal error: Erreur de segmentation

L'ouverture du même fichier avec Gimp (gimp-ufraw):

(gimp:2901): GLib-GObject-WARNING **: 09:37:39.581: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size'

(gimp:2901): Gimp-Widgets-CRITICAL **: 09:37:39.855: gimp_device_info_set_device: assertion '(info->device == NULL && GDK_IS_DEVICE (device)) || (GDK_IS_DEVICE (info->device) && device == NULL)' failed

Puis, au moment de valider et d'envoyer à Gimp:

(ufraw-gimp:2912): GLib-GObject-CRITICAL **: 07:40:41.162: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

(ufraw-gimp:2912): GLib-GObject-CRITICAL **: 07:40:41.162: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
/usr/lib/gimp/2.0/plug-ins/ufraw-gimp: fatal error: Erreur de segmentation

J'éspère que ça sera utile,
Merci de ton intérêt pour la question !

Hors ligne

#4 Le 29/06/2018, à 10:04

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

Tes applis d'imagerie ne sont pas en snap : une cause possible d'éliminée !  smile

  - -

phidu a écrit :
/usr/lib/gimp/2.0/plug-ins/ufraw-gimp: fatal error: Erreur de segmentation
Erreur de segmentation (core dumped)

Aïe !
Soit il y a un bug qui sera réparé à l'occasion d'une mise à jour,
soit c'est le disque qui est abîmé à l'endroit supportant gimp ou ufraw-gimp.


Version des applis
  Montre :

cat /etc/apt/sources.list.d/*.list | grep -v ^#
dpkg -l | grep -E "gimp|ufraw"

État du disque :
  Si tu n'as qu'un disque, montre :

sudo smartctl -s on -a /dev/sda

  Sinon, montre déjà :

sudo lsblk -o name,fstype,size,mountpoint

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#5 Le 29/06/2018, à 10:41

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

moko138 a écrit :

Tes applis d'imagerie ne sont pas en snap

Ah. Et qu'est-ce donc que le snap ? (désolé).

moko138 a écrit :
cat /etc/apt/sources.list.d/*.list | grep -v ^#

donne:

cat: '/etc/apt/sources.list.d/*.list': Aucun fichier ou dossier de ce type
moko138 a écrit :
dpkg -l | grep -E "gimp|ufraw"
ii  gimp                                          2.8.22-1                            amd64        GNU Image Manipulation Program
ii  gimp-data                                     2.8.22-1                            all          Data files for GIMP
ii  gimp-help-common                              2.8.2-0.1                           all          Data files for the GIMP documentation
ii  gimp-help-fr                                  2.8.2-0.1                           all          Documentation for the GIMP (French)
ii  gimp-ufraw                                    0.22-3                              amd64        gimp importer for raw camera images
ii  libgimp2.0                                    2.8.22-1                            amd64        Libraries for the GNU Image Manipulation Program
ii  ufraw                                         0.22-3                              amd64        standalone importer for raw camera images
ii  ufraw-batch                                   0.22-3                              amd64        batch importer for raw camera images
moko138 a écrit :
sudo smartctl -s on -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-23-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     SAMSUNG SSD PM851 mSATA 256GB
Serial Number:    S1EVNSAF702468
LU WWN Device Id: 5 002538 844584d30
Firmware Version: EXT49D0Q
User Capacity:    256'060'514'304 bytes [256 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Jun 29 11:36:32 2018 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enabled.

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(    0) seconds.
Offline data collection
capabilities: 			 (0x53) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					No Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  80) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       489
175 Program_Fail_Count_Chip 0x0032   100   100   010    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   010    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0013   096   096   005    Pre-fail  Always       -       44
178 Used_Rsvd_Blk_Cnt_Chip  0x0013   100   100   010    Pre-fail  Always       -       0
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013   100   100   010    Pre-fail  Always       -       4387
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       11575154727
242 Total_LBAs_Read         0x0032   099   099   000    Old_age   Always       -       6941644423

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%         0         -
# 2  Extended offline    Completed without error       00%         2         -
# 3  Short offline       Completed without error       00%         0         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Hors ligne

#6 Le 29/06/2018, à 16:45

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

Sur gimp en particulier et snap en général, je te recommande cette discussion ./viewtopic.php?id=2025700
  - -

smart
  Je ne suis pas fort en ssd.
À cette réserve près, ce que je comprends du rapport me suugère un ssd sain.
  - -

Je ne vois pas de ppa ;
tes gimp et ufraw me semblent d'être les saines versions des dépôts officiels. smile
À moins que gimp 2.8.22-1... ? Montre :

cat /etc/apt/sources.list | grep -v ^#

mais je crains de sécher...


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#7 Le 29/06/2018, à 21:12

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

moko138 a écrit :
cat /etc/apt/sources.list | grep -v ^#
deb http://ubuntu.ethz.ch/ubuntu/ bionic main restricted

deb http://ubuntu.ethz.ch/ubuntu/ bionic-updates main restricted

deb http://ubuntu.ethz.ch/ubuntu/ bionic universe
deb http://ubuntu.ethz.ch/ubuntu/ bionic-updates universe

deb http://ubuntu.ethz.ch/ubuntu/ bionic multiverse
deb http://ubuntu.ethz.ch/ubuntu/ bionic-updates multiverse

deb http://ubuntu.ethz.ch/ubuntu/ bionic-backports main restricted universe multiverse


deb http://ubuntu.ethz.ch/ubuntu/ bionic-security main restricted
deb http://ubuntu.ethz.ch/ubuntu/ bionic-security universe
deb http://ubuntu.ethz.ch/ubuntu/ bionic-security multiverse

je suis sur le miroir de l'ethz parce qu'ils propose l'http, le port ftp étant limité quand on partage la 4g (je suis assez nomade).

A propos des snap, je vais me renseigner, mais ce que j'en comprends c'est qu'un même logiciel installé via apt-get (.deb) ou via un snap, pourrait présenter des différences ? Et cette notion de "bac à sable m'inquiète un peu, ça pourrait être à l'origine de la difficulter de communiquation entre ufraw et gimp...

Dans tout les cas, il me semble avoir installé mes appli comme toujours, avec synaptic...

Je vais creuser...

Merci pour ton coup de main !

Hors ligne

#8 Le 29/06/2018, à 21:51

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

Tes applis et tes dépôts aussi sont clairs.
Relis le présent fil avant de partir en quête d'infos que tu as déjà.  smile

Cela dit, je sèche, attendons du renfort !


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#9 Le 29/06/2018, à 22:34

??

Re : Bug de Gimp-ufraw sur Bionic Beaver

moko138 a écrit :

  - -

phidu a écrit :
/usr/lib/gimp/2.0/plug-ins/ufraw-gimp: fatal error: Erreur de segmentation
Erreur de segmentation (core dumped)

Aïe !
Soit il y a un bug qui sera réparé à l'occasion d'une mise à jour,
soit c'est le disque qui est abîmé à l'endroit supportant gimp ou ufraw-gimp.

Bonsoir
+1

et sur le cas bug car la suite montre que tu as un SSD..

et un SSD cela fonctionne tant que ce n'est pas failing now
Ce qui est loin d'être le cas, car il n'a consommé que 4%  (100-96) de sa réserve de carburant.

177 Wear_Leveling_Count     0x0013   096  096   005    Pre-fail  Always       -       44

j'ai noté que samsung n'enregistre pas le temps de fonctionnement.

Dernière modification par ?? (Le 29/06/2018, à 22:38)


Utiliser REFIND au lieu du GRUB https://doc.ubuntu-fr.org/refind . Aidez à vous faire dépanner en suivant le guide et en utilisant les outils de diagnostic J'ai perdu ma gomme. Désolé pour les fautes d'orthographes non corrigées.

Hors ligne

#10 Le 29/06/2018, à 23:13

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

Merci ?? !

  - -

phidu a écrit :

Le problème est le même sur plusieurs machines, des installations à partir d'iso différentes et persiste après plusieurs mises à jour.

Ufraw seul, fonctionne correctement mais je dois alors passer par l'enregistrement d'un fichier .ppm, puis l'ouvrir dans Gimp

Donc on s'oriente vers un bug de l'intégration de gimp et de gimp-ufraw dans la récente Bionic.
Cf. ./viewtopic.php?pid=21912913#p21912913


Ce qui est bizarre, c'est que je ne trouve pas ce bug sur la toile.


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#11 Le 30/06/2018, à 02:28

Coeur Noir

Re : Bug de Gimp-ufraw sur Bionic Beaver

Hmm, ouep pas évident… un truc approchant :
https://sourceforge.net/p/ufraw/discuss … /f9f5e014/
…mais datant d'Ubuntu 12.10 ( un problème avec un compileur gcc à ce moment là )

De fil en aiguille : https://launchpad.net/ubuntu/+source/ufraw
Et par là on trouve aussi des segfault avec ufraw https://bugs.launchpad.net/ubuntu/+sour … ug/1768855 aucune idée s'il s'agit exactement du même pépin cependant…

Certains semblent carrément se demander si ufraw est encore vivant https://sourceforge.net/p/ufraw/discuss … /3b32cef6/
D'après ces liens, je ne vois rien de plus récent que janvier 2017 le concernant…

Pour moi il y aurait 2 ou 3 choses à tester :
- est-ce que sous Ubuntu 16.04 tout se passe comme prévu ?
- est-il possible sous 18.04 de « bloquer » la version d'ufraw idem à ce qu'il y avait dans la 16.04, et voir ce que ça donne ? ( le .deb est par là https://packages.ubuntu.com/xenial/ufraw )
- est-ce que compiler sous 18.04 ufraw depuis ses sources les plus récentes rétablit une situation normale ?

Avec Gimp 2.10, c'est plutôt DarkTable ( voir aussi https://darktable.fr/ ) et en second choix RawTherapee qui sont recommandés pour le traitement raw. DarkTable travaille en 32 bits, contrairement à UfRaw.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#12 Le 30/06/2018, à 07:03

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

Merci Coeur Noir !
  - -

À noter : jusqu'à hier soir, je n'avais pas ufraw d'installé, dans ma Lubuntu Trusty, 32 bits ; seulement gimp-ufraw.
  - -

Merci de montrer cette simulation :

sudo apt-get -s remove --purge ufraw

  et

cat /etc/fstab

  - -

Plus j'y pense, plus le suspect est caché derrière le mot "widgets". D'ailleurs une recherche avec

"Gimp-Widgets-CRITICAL" 2018

donne des pistes intéressantes que je n'ai pas fini d'explorer.

Donc :
       Tests à faire :
a) en choisissant bien sûr un .NEF ayant précédemment été mêlé au dysfonctionnement, lancer

gimp --verbose un-fichier.NEF

Après plantage, tu fermes - s'ils ne se sont pas déjà fermés d'eux-mêmes - gimp et gimp-ufraw ;
puis tu montres le retour complet.


b) Tu ouvres un autre onglet
Tu recommences, mais avec une nuance (options -sdf) :
en choisissant le même .NEF que précédemment, lancer

gimp --verbose -sdf un-fichier.NEF

Après plantage ou réussite, tu fermes - s'ils ne se sont pas déjà fermés d'eux-mêmes - gimp et gimp-ufraw ;
puis, quel que soit le résultat, tu montres le retour complet.


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#13 Le 30/06/2018, à 19:57

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

ça marche !

par contre désolé pour ceux qui aurait éventuellement eu le même problème car la solution que j'ai trouvé n'en est pas vraiment une: ré-installation complète du système (avec une nouvelle image iso).
Merci à tous pour votre aide mais j'avoue que je commençais à trouver ça bien compliqué pour quelque chose qui est sensé fonctionner sans problème.
L'absence totale de sujet concernant mon problème m'a fait pensé que c'était un malheureux concours de circonstance (ordre d'installation des paquets ? iso défectueuse ?)...

Bref ça fonctionne maintenant correctement...

Désolé pour la perte de temps !

Hors ligne

#14 Le 01/07/2018, à 10:34

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

En #1, phidu a écrit :

Le problème est le même sur plusieurs machines, des installations à partir d'iso différentes et persiste après plusieurs mises à jour.

En #13, phidu a écrit :

la solution que j'ai trouvé n'en est pas vraiment une: ré-installation complète du système (avec une nouvelle image iso).

Euh... "avec une nouvelle image iso", tu as procédé à une "ré-installation complète du système" "sur plusieurs machines" ???


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#15 Le 01/07/2018, à 13:21

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

moko138 a écrit :

Euh... "avec une nouvelle image iso", tu as procédé à une "ré-installation complète du système" "sur plusieurs machines" ???

Sur deux machines. Sur l'une j'avais migré depuis la 17.10 (j'avoue que je ne me souviens plus exactement de quelle manière) Et sur l'autre, une installation réalisée par une tierce personne avec la toute première iso disponible chez canonical.

ça peut paraître étrange que je ne soit pas plus au clair que ça sur les install de mes machines, mais en fait, je récupère des ordi d'occase et fait des test avec, en tout j'en ai quatre. (il n'y a pas très longtemps j'avais juste un mac).
Mais je crois que j'ai trouvé mon bonheur avec un HP z600 dans mon "studio", un dell latitude e7440 comme portable et un HP compaq à la maison pour la famille.

J'ai testé debian puis ubuntu, avec gnome et xfce. Et malgré mon envie d'être sur debian, j'avoue que je galère moins sur ubuntu, quoique cette dernière aventure avec ufraw m'ait fait douter...

Je vais maintenant vérifier que le bug ne ré-apparaît pas, mais à première vue ça a l'air stable.

Hors ligne

#16 Le 01/07/2018, à 22:46

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

Ahhrg ! Le bug est revenu !

Le pire dans tout ça c'est qu'au moment de valider depuis ufraw, je suis déjà sur une photo depuis peut-être une demie-heure et... tout le travail est perdu.

Bon cela dit, le fait d'avoir tout ré-installé m'a fait repasser par les étapes qui ont précédé au bug et du coup, j'ai une piste:

Dernière manip avant la ré-apparition de l'horrible message d'erreur: j'ai coché la case "mémoriser ce choix" au moment de choisir Gimp pour ouvrir un fichier depuis digikam.
J'avais ouvert les fichiers précédents en faisant "ouvrir avec" depuis digikam, et choisi Gimp sans mémoriser mon choix et tout c'est passé sans problème entre ufraw et gimp.
Je coche cette case (qui d'ailleurs ne mémorise pas mon choix du tout) et le bug revient.
ça parait un peu tiré par les cheveux, mais bon après tout, c'est de l'informatique... tout est possible.

Je suis en train de ré-installer digikam...

Je vous tient au courant.

Hors ligne

#17 Le 01/07/2018, à 23:06

Coeur Noir

Re : Bug de Gimp-ufraw sur Bionic Beaver

Je me demande si ta méthode pour récupérer tes fichiers raw ne serait pas plus compliquée que nécessaire ?

Ça dépend beaucoup de ce que tu veux en faire, de ces fichiers, bien entendu.

S'il s'agit de traitement purement photographique, jette un œil voire deux à DarkTable il est généralement bien apprécié des photographes et à priori enlèverait gimp de l'équation.

Ça ne veut pas dire que gimp est fautif ( je pencherais plutôt pour un bug avec ufraw ) mais puisque tes images issues de DarkTable seront belles et éclatantes, pourquoi les re-mouliner dans gimp ensuite ?


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#18 Le 01/07/2018, à 23:17

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

Coeur Noir a écrit :

Je me demande si ta méthode pour récupérer tes fichiers raw ne serait pas plus compliquée que nécessaire ?

Ça dépend beaucoup de ce que tu veux en faire, de ces fichiers, bien entendu.

S'il s'agit de traitement purement photographique, jette un œil voire deux à DarkTable il est généralement bien apprécié des photographes et à priori enlèverait gimp de l'équation.

Ça ne veut pas dire que gimp est fautif ( je pencherais plutôt pour un bug avec ufraw ) mais puisque tes images issues de DarkTable seront belles et éclatantes, pourquoi les re-mouliner dans gimp ensuite ?

J'utilise Gimp pour des corrections qui ne sont pas disponibles dans Ufraw (comme des retouches spécifiques à certaines zone de l'image) mais également pour retailler l'image et l'exporter.
Mais je vais suivre ton conseil et m'intéresser à Darktable.
Je croyais avoir trouvé une bonne combinaison de logiciel et pouvoir enfin passer du temps sur de l'artistique plutôt que de la technique, mais bon... va pour découvrir une nouvelle app.

Par contre, pas sûr que Darktable supporte mon fonctionnement "nomade", je travaille sur plusieurs machines et donc sur clé usb, j'évite donc de travailler avec une application qui dépend d'une base de donnée locale...

Dernière modification par phidu (Le 01/07/2018, à 23:30)

Hors ligne

#19 Le 02/07/2018, à 00:45

Coeur Noir

Re : Bug de Gimp-ufraw sur Bionic Beaver

Ah. Je ne sais pas s'il existe une version « portable » de DarkTable : le logiciel ( et sa base de données, ses fichiers de config's ) seraient alors sur la clé usb ?

À moins que tu puisses spécifier dans les préférences de DT un chemin pour cette bdd ( que tu copierais alors sur la clé usb nomade au besoin )…


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#20 Le 02/07/2018, à 12:15

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

En tout cas, darktable, pour ce qui est du développement, est nettement supérieur à ufraw ! Sans parler de l'historique !

Je vais creuser cette histoire de base de donnée locale et faire des test sur des copie de répertoire avant d'importer toute mes photos pour voir comment on retrouve son travail sur un autre poste. Peut être que les fichier xmp suffisent à transmettre les infos. Mais ce qui m'embète dans ce fonctionnement c'est la compatibilité avec d'autre applications. Que se passera-t-il si un jour je dois récupérer mon travail en dehors de Darktable...

Enfin, je crois qu'on s'éloigne du sujet d'origine...

Merci pour les conseils !

Hors ligne

#21 Le 02/07/2018, à 13:15

Coeur Noir

Re : Bug de Gimp-ufraw sur Bionic Beaver

DT ne modifie pas le fichier raw initial.
Il enregistre les différents filtres, réglages et actions que tu appliques à ce fichier.
Le fichier généré par DT c'est ton raw intact + un instantané de tes actions. Ça n'est pas l'image résultante qui est enregistrée,  ça ce serait plutôt un export vers tif PDF png ou autre.
Le « travail » paraît donc exportable, et modifiable, tout en préservant le raw initial.

Ce que tu risques de ne pas retrouver d'une machine à l'autre, c'est l'historique des manipulations sur le fichier.
Enfin, si, tu retrouveras un historique par machine mais pas un global par rapport à ce fichier.

Et encore... Ça se trouve y a moyen d'enregistrer tout ça avec lui, voir les diverses options d'export et d'enregistrement dans DT là j'avoue que je ne connais pas assez le logiciel.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#22 Le 02/07/2018, à 17:12

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

phidu a écrit :
moko138 a écrit :

Euh... "avec une nouvelle image iso", tu as procédé à une "ré-installation complète du système" "sur plusieurs machines" ???

Sur deux machines. Sur l'une j'avais migré depuis la 17.10 (j'avoue que je ne me souviens plus exactement de quelle manière) Et sur l'autre, une installation réalisée par une tierce personne avec la toute première iso disponible chez canonical.

ça peut paraître étrange que je ne soit pas plus au clair que ça sur les install de mes machines, mais en fait, je récupère des ordi d'occase et fait des test avec, en tout j'en ai quatre. (il n'y a pas très longtemps j'avais juste un mac).
Mais je crois que j'ai trouvé mon bonheur avec un HP z600 dans mon "studio", un dell latitude e7440 comme portable et un HP compaq à la maison pour la famille.

Ça, ça ressemble à trois machines,
et à des sessions installées sur disque interne.
  - -

phidu a écrit :

pas sûr que Darktable supporte mon fonctionnement "nomade", je travaille sur plusieurs machines et donc sur clé usb, j'évite donc de travailler avec une application qui dépend d'une base de donnée locale...

Es-tu en session installée sur disque externe ?
     En live persistant ?
     En live non persistant ?
     Autre ?

Merci de nous éclairer...


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#23 Le 02/07/2018, à 23:18

Coeur Noir

Re : Bug de Gimp-ufraw sur Bionic Beaver

Oh, là je crois que  tu te compliques l'analyse moko. PhiDu confirmera si j'ai compris :

…il aime bien bidouiller ses images raw un peu n'importe et où et quand, donc pas toujours sur le même ordi' et en stockant sur une clé USB les images à travailler.
L'idée c'est de savoir si on ne perd pas trop d'infos sur l'historique des actions effectuées sur un fichier raw, en passant d'un DarkTable à un autre ( tout dépend de ce que DT enregistre directement avec le fichier et ce qu'il stocke localement sur chaque pc dans sa base de données ).


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#24 Le 07/07/2018, à 13:11

phidu

Re : Bug de Gimp-ufraw sur Bionic Beaver

moko138 a écrit :

Ça, ça ressemble à trois machines,
et à des sessions installées sur disque interne.

Deux machines que j'utilise activement dans le cas qui nous intéresse et sur lesquelles le bug s'est déclaré (DELL LATITUDE et HP COMPAQ) et sur lesquelles j'ai refait l'installation complète, plus une sur laquelle le bug ne s'est pas déclaré (HP Z600)car je n'avais pas encore coché la fameuse case de digikam "mémoriser mon choix" concernant l'ouverture d'un fichier RAW, quand à la quatrième, ne l'utilisant pas pour la photo, je n'aurais pas du la mentionner, toute mes excuses pour le manque de précision.

moko138 a écrit :

Es-tu en session installée sur disque externe ?
     En live persistant ?
     En live non persistant ?
     Autre ?

Merci de nous éclairer...

Je ne suis pas sûr de comprendre ta question à propos d'un live persistant ou non, cela concerne les systeme qui tournent sur clé usb, non ?
Dans mon cas, comme le relève Coeur Noir, ce sont seulement mes fichiers photos qui sont sur clé usb.

coeur noir a écrit :

L'idée c'est de savoir si on ne perd pas trop d'infos sur l'historique des actions effectuées sur un fichier raw, en passant d'un DarkTable à un autre ( tout dépend de ce que DT enregistre directement avec le fichier et ce qu'il stocke localement sur chaque pc dans sa base de données ).

Tout à fait, et j'ai justement testé DT un peu plus profondément: l'historique aussi est inscrit dans les fichier xmp ! Ce qui signifie que je peux reprendre l'intégralité de mon travail sur un autre poste sans soucis. La base de donnée sert visiblement surtout à mémoriser les répertoires et fichiers importés et l'état de DT à la fermeture (et sûrement d'autres fonctions que je n'ai pas encore découvertes).
En clair cela signifie qu'à la réouverture de DT sur un nouveau poste, mieux vaut vider la base et ré-importer la pélicule pour qu'il prenne en compte les éventuels nouveau répertoires ou modifications concernant les noms de fichiers ou suppresion et ajout de fichiers.

Je ne vais donc pas utiliser DT comme gestionnaire de fichier comme je le faisait avec Digikam, mais "juste" pour développer mes photos, un projet à la fois.
ça me convient parfaitement, et tant pis pour ufraw et digikam.

Je sais que nous n'avons pas trouvé de solution pour le bug qui m'a amené à ouvrir ce sujet, mais dans mon cas, ayant décidé de ne plus utiliser ufraw, je vais arrêter les tests.

Merci encore, Coeur Noir et Moko138 pour votre aide !

Hors ligne

#25 Le 07/07/2018, à 15:12

moko138

Re : Bug de Gimp-ufraw sur Bionic Beaver

ce sont seulement mes fichiers photos qui sont sur clé usb.

Cela répond à ma question.  smile
  - -

nous n'avons pas trouvé de solution pour le bug qui m'a amené à ouvrir ce sujet, mais

Mais ton hypothèse que ce qui coinçait, c'était ton choix de confier à digikam le soin d'appeler gimp-ufraw pour ouvrir les .NEF, cette hypothèse me paraît plausible.


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne