rickub
fonzarely/regine-photos-archiverpublic⑂ Fork 0
⑂ afe38a4
Branches
main View all branches → View all tags →
Commits
⬇ Clone ▾
git clone https://git.rickub.com/fonzarely/regine-photos-archiver.git
git clone ssh://git@rickub.com/fonzarely/regine-photos-archiver.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

import carte

Fabien Champigny committed 2026-09-09T16:03:06+02:00 Browse files
afe38a4 parent: 7ceaa34
modified docs/archivage-photo-elements-cles.md +22 -0
@@ -72,6 +72,27 @@ Points à anticiper pour l'implémentation :
7272 - Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle.
7373 - Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW.
7474
75+## 10. Import depuis une carte mémoire
76+
77+Cas d'usage : fin de journée de prise de vue, ou retour de vacances — intégrer le contenu d'une carte mémoire dans un ou plusieurs projets, en préparation de l'archivage (en amont du workflow de la section 9).
78+
79+Séquence retenue :
80+
81+1. **Copie brute vers un dossier temporaire local** (nom neutre, pas encore le nom final du projet), avec vérification checksum fichier par fichier pendant la copie. Ne jamais considérer la carte comme "sûre à effacer" tant que cette vérification n'est pas passée (idéalement tant qu'une deuxième copie n'existe pas non plus, cf. règle 3-2-1 en section 5).
82+2. **Analyse EXIF** de la copie locale : lecture de la date de prise de vue (`DateTimeOriginal`, pas la date de fichier) sur chaque fichier importé, pour construire une répartition jour par jour (nombre de photos, plage horaire) du lot.
83+ - Ne prendre en compte que les fichiers réellement nouveaux pour cet import (comparaison par checksum avec les imports précédents), pas d'anciens fichiers restés sur la carte d'un import antérieur non effacé.
84+ - Détecter les dates aberrantes (horloge d'appareil réinitialisée après batterie vide, ex. dates en 1980/2002) : les exclure du calcul de plage et signaler l'anomalie à l'utilisateur plutôt que fausser silencieusement la plage détectée.
85+3. **Proposition de découpage en un ou plusieurs projets** à partir de cette répartition jour par jour. Par défaut, un seul projet pour toute la plage contiguë détectée, mais l'utilisateur doit pouvoir détacher un ou plusieurs jours pour en faire des projets séparés (cas type : une semaine de vacances avec un anniversaire au milieu, à isoler dans son propre projet). Régine peut mettre en avant des candidats plausibles (ex. un pic de photos concentré sur quelques heures, différent du reste), mais seulement comme suggestion — une détection automatique et définitive du type d'événement à partir des seuls horodatages n'est pas fiable et ne doit pas décider à la place de l'utilisateur.
86+4. **Titre** demandé pour chaque projet résultant, nettoyé pour servir de nom de dossier (espaces → underscores, interdiction des caractères invalides `/ \ : * ? " < >`), puis combiné à la plage de dates :
87+ - un jour unique : `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`)
88+ - une plage dans le même mois : `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace` = du 11 au 20 août 2026)
89+ - une plage à cheval sur deux mois/années : forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois)
90+ - si un jour est extrait du milieu d'une plage contiguë pour devenir son propre projet, le projet restant garde le nom de la plage d'origine (ex. 11–17 août même si le 13 en est sorti) plutôt que de recalculer un nom qui ne refléterait que les jours effectivement inclus — plus simple, et le nom du dossier n'a pas besoin d'être une description exacte au jour près.
91+5. **Vérification de collision** avant de créer le dossier final dans l'archive : si un projet du même nom existe déjà, proposer un suffixe ou demander confirmation plutôt que d'écraser.
92+6. Les fichiers gardent leur nom d'origine donné par l'appareil (pas de renommage à l'import) — cohérent avec la section 3 : l'identifiant pérenne est attribué séparément par Régine à ce moment d'entrée dans le système, indépendamment du nom de fichier.
93+7. Gestion des collisions de noms entre sources (deux cartes/boîtiers avec les mêmes noms de fichier de type `IMG_0001.CR2`) : comparer par checksum avant de traiter un nom identique comme un doublon ; sinon garder les deux fichiers distincts (sous-dossier par source, par exemple).
94+8. Une fois le(s) dossier(s) projet finalisé(s) en local, ils sont poussés vers l'archive NAS — même logique de copie vérifiée qu'à l'étape 1, plutôt qu'une copie directe carte → NAS (plus lente et plus fragile aux coupures réseau).
95+
7596 ## Pistes de fonctionnalités pour Régine
7697
7798 - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.
@@ -81,6 +102,7 @@ Points à anticiper pour l'implémentation :
81102 - Gestion de niveaux de sélection (brut / sélection / édition finale).
82103 - Champs de droits/licence par photo ou par lot.
83104 - Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 9.
105+- Import carte mémoire : copie locale vérifiée, détection de plage de dates par EXIF (avec gestion des dates aberrantes), proposition de découpage en plusieurs projets à partir de la répartition jour par jour — cf. section 10.
84106
85107 ## Sources
86108
@@ -72,6 +72,27 @@ Points à anticiper pour l'implémentation :
72 - Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle.72 - Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle.
73 - Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW.73 - Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW.
74 74
75+## 10. Import depuis une carte mémoire
76+
77+Cas d'usage : fin de journée de prise de vue, ou retour de vacances — intégrer le contenu d'une carte mémoire dans un ou plusieurs projets, en préparation de l'archivage (en amont du workflow de la section 9).
78+
79+Séquence retenue :
80+
81+1. **Copie brute vers un dossier temporaire local** (nom neutre, pas encore le nom final du projet), avec vérification checksum fichier par fichier pendant la copie. Ne jamais considérer la carte comme "sûre à effacer" tant que cette vérification n'est pas passée (idéalement tant qu'une deuxième copie n'existe pas non plus, cf. règle 3-2-1 en section 5).
82+2. **Analyse EXIF** de la copie locale : lecture de la date de prise de vue (`DateTimeOriginal`, pas la date de fichier) sur chaque fichier importé, pour construire une répartition jour par jour (nombre de photos, plage horaire) du lot.
83+ - Ne prendre en compte que les fichiers réellement nouveaux pour cet import (comparaison par checksum avec les imports précédents), pas d'anciens fichiers restés sur la carte d'un import antérieur non effacé.
84+ - Détecter les dates aberrantes (horloge d'appareil réinitialisée après batterie vide, ex. dates en 1980/2002) : les exclure du calcul de plage et signaler l'anomalie à l'utilisateur plutôt que fausser silencieusement la plage détectée.
85+3. **Proposition de découpage en un ou plusieurs projets** à partir de cette répartition jour par jour. Par défaut, un seul projet pour toute la plage contiguë détectée, mais l'utilisateur doit pouvoir détacher un ou plusieurs jours pour en faire des projets séparés (cas type : une semaine de vacances avec un anniversaire au milieu, à isoler dans son propre projet). Régine peut mettre en avant des candidats plausibles (ex. un pic de photos concentré sur quelques heures, différent du reste), mais seulement comme suggestion — une détection automatique et définitive du type d'événement à partir des seuls horodatages n'est pas fiable et ne doit pas décider à la place de l'utilisateur.
86+4. **Titre** demandé pour chaque projet résultant, nettoyé pour servir de nom de dossier (espaces → underscores, interdiction des caractères invalides `/ \ : * ? " < >`), puis combiné à la plage de dates :
87+ - un jour unique : `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`)
88+ - une plage dans le même mois : `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace` = du 11 au 20 août 2026)
89+ - une plage à cheval sur deux mois/années : forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois)
90+ - si un jour est extrait du milieu d'une plage contiguë pour devenir son propre projet, le projet restant garde le nom de la plage d'origine (ex. 11–17 août même si le 13 en est sorti) plutôt que de recalculer un nom qui ne refléterait que les jours effectivement inclus — plus simple, et le nom du dossier n'a pas besoin d'être une description exacte au jour près.
91+5. **Vérification de collision** avant de créer le dossier final dans l'archive : si un projet du même nom existe déjà, proposer un suffixe ou demander confirmation plutôt que d'écraser.
92+6. Les fichiers gardent leur nom d'origine donné par l'appareil (pas de renommage à l'import) — cohérent avec la section 3 : l'identifiant pérenne est attribué séparément par Régine à ce moment d'entrée dans le système, indépendamment du nom de fichier.
93+7. Gestion des collisions de noms entre sources (deux cartes/boîtiers avec les mêmes noms de fichier de type `IMG_0001.CR2`) : comparer par checksum avant de traiter un nom identique comme un doublon ; sinon garder les deux fichiers distincts (sous-dossier par source, par exemple).
94+8. Une fois le(s) dossier(s) projet finalisé(s) en local, ils sont poussés vers l'archive NAS — même logique de copie vérifiée qu'à l'étape 1, plutôt qu'une copie directe carte → NAS (plus lente et plus fragile aux coupures réseau).
95+
75 ## Pistes de fonctionnalités pour Régine96 ## Pistes de fonctionnalités pour Régine
76 97
77 - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.98 - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.
@@ -81,6 +102,7 @@ Points à anticiper pour l'implémentation :
81 - Gestion de niveaux de sélection (brut / sélection / édition finale).102 - Gestion de niveaux de sélection (brut / sélection / édition finale).
82 - Champs de droits/licence par photo ou par lot.103 - Champs de droits/licence par photo ou par lot.
83 - Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 9.104 - Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 9.
105+- Import carte mémoire : copie locale vérifiée, détection de plage de dates par EXIF (avec gestion des dates aberrantes), proposition de découpage en plusieurs projets à partir de la répartition jour par jour — cf. section 10.
84 106
85 ## Sources107 ## Sources
86 108