je me méfie paranoiaquement des outils genre cleaner.sh
linux mint a un outil pour monter automatiquement des disques dans des dossiers... les disques peuvent se reconnaître selon des LABELS ou via l'arborescence système et donc le programme Linux mint (preferences/disques) fait le lien entre les infos du disque et un dossier. Alors on importe les images selon le point de montage donc les infos disque.
ensuite on change quelque chose, fait une mise à jour et le disque a des infos différentes. Alors le disque se monte en /media/$USER/145-48CD un truc du genre.
Ensuite darktable affiche des têtes de mort. Il trouve pas les photos. Alors je lance la fonction clean. qui va virer tout ce qui est sur le disque monté ailleurs. donc apres la manip je remarque le probleme et je monte le disque à l'endroit précédent. et je réimporte les photos quitte à passer 2 heures pour tout relancer.. importer dossier
/media/disque Photos/Photos/
admettons que j'ai pas mis les xmp. Il faut que les bases de données fonctionnent via des liens. une photo importée a un numero d'identifiant. lorsque dans un autre traitement on veut dire traitement image dsc2563.nef l'image a un numero dans la liste des images exemple 15000. Alors quelque part on a 15000 et le traitement pour l'image 15000
si on vire l'image dans la base le numero dans le traitement reste en place. ou alors c'est que l'on fait disparaître le traitement également.
le probleme c'est que si on réimporte l'image est le numero sera le même que dans le traitement ou alors sera différent.
A coup sur, il sera différent... parce que les algos prennent la valeur maxi des identifiants + 1 et on obtient la valeur. ou alors dans les traitements on doit avoir une fonction commune entre la liste des photos et celle des traitements. et donc si tel est le cas on peut remettre les identifiants 'en face l'un de l'autre'. Une solution est de mettre la date de création de la photo dans les deux endroits... mais pourquoi alors mettre un id numérique pour pas prendre de place alors que l'on a également une information comme
20170711-122548,985ms alors qu'un identifiant correspond au pire à 12cd7857 en hexa. 18 octets au lieu de 4. chercher l'erreur.
moi j'ai programme sur des bases de données. ca devient très vite infernal. Ou alors on applique des règles très restrictives et pour résumer on ne revient jamais en arrière.
les problemes c'est lorsque on exporte vers l'extérieur du programme et ensuite on réimporte apres les traitements. la seule solution c'est de faire un double.
image 15000 ---> export des manips ---> traitement extérieur ----> et relecture numero 125489 ---> effacement enregistrement 15000 et des traitements.. là ca va marcher.
ou alors on fait une table 15000 transformée en 125489 avec un libelle "travail dans gimp".
je suis pas fan du tout des trucs genre effacetout.sh
linux mint a un outil pour monter automatiquement des disques dans des dossiers... les disques peuvent se reconnaître selon des LABELS ou via l'arborescence système et donc le programme Linux mint (preferences/disques) fait le lien entre les infos du disque et un dossier. Alors on importe les images selon le point de montage donc les infos disque.
ensuite on change quelque chose, fait une mise à jour et le disque a des infos différentes. Alors le disque se monte en /media/$USER/145-48CD un truc du genre.
Ensuite darktable affiche des têtes de mort. Il trouve pas les photos. Alors je lance la fonction clean. qui va virer tout ce qui est sur le disque monté ailleurs. donc apres la manip je remarque le probleme et je monte le disque à l'endroit précédent. et je réimporte les photos quitte à passer 2 heures pour tout relancer.. importer dossier
/media/disque Photos/Photos/
admettons que j'ai pas mis les xmp. Il faut que les bases de données fonctionnent via des liens. une photo importée a un numero d'identifiant. lorsque dans un autre traitement on veut dire traitement image dsc2563.nef l'image a un numero dans la liste des images exemple 15000. Alors quelque part on a 15000 et le traitement pour l'image 15000
si on vire l'image dans la base le numero dans le traitement reste en place. ou alors c'est que l'on fait disparaître le traitement également.
le probleme c'est que si on réimporte l'image est le numero sera le même que dans le traitement ou alors sera différent.
A coup sur, il sera différent... parce que les algos prennent la valeur maxi des identifiants + 1 et on obtient la valeur. ou alors dans les traitements on doit avoir une fonction commune entre la liste des photos et celle des traitements. et donc si tel est le cas on peut remettre les identifiants 'en face l'un de l'autre'. Une solution est de mettre la date de création de la photo dans les deux endroits... mais pourquoi alors mettre un id numérique pour pas prendre de place alors que l'on a également une information comme
20170711-122548,985ms alors qu'un identifiant correspond au pire à 12cd7857 en hexa. 18 octets au lieu de 4. chercher l'erreur.
moi j'ai programme sur des bases de données. ca devient très vite infernal. Ou alors on applique des règles très restrictives et pour résumer on ne revient jamais en arrière.
les problemes c'est lorsque on exporte vers l'extérieur du programme et ensuite on réimporte apres les traitements. la seule solution c'est de faire un double.
image 15000 ---> export des manips ---> traitement extérieur ----> et relecture numero 125489 ---> effacement enregistrement 15000 et des traitements.. là ca va marcher.
ou alors on fait une table 15000 transformée en 125489 avec un libelle "travail dans gimp".
je suis pas fan du tout des trucs genre effacetout.sh
uc sedateck 8 go ram
appareil D5100 - objectif nikkor 18-55G 1:3.5-5.6 VR
objectif samyang AE 14mm 1:2.8
-----
ordinateur de burreau,
1TO disque dur, 240 GO SSD
8 GO de ram
carte video + gpu
raspberry pi 4 2GO
darktable 4.4.2
appareil D5100 - objectif nikkor 18-55G 1:3.5-5.6 VR
objectif samyang AE 14mm 1:2.8
-----
ordinateur de burreau,
1TO disque dur, 240 GO SSD
8 GO de ram
carte video + gpu
raspberry pi 4 2GO
darktable 4.4.2