| @@ -19,6 +19,7 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections |
| 19 | | 19 | |
| 20 | - Chaque image a un identifiant pérenne (numéro de négatif/planche/rouleau) qui ne change jamais, indépendant du nom de fichier. | 20 | - Chaque image a un identifiant pérenne (numéro de négatif/planche/rouleau) qui ne change jamais, indépendant du nom de fichier. |
| 21 | - Permet de relier les différentes versions d'une même image (scan brut, retouche, tirage) dans le temps. | 21 | - Permet de relier les différentes versions d'une même image (scan brut, retouche, tirage) dans le temps. |
| | 22 | +- Complémentaire à ça, le nom de fichier archivé suit désormais une convention lisible qui encode la provenance (projet/date) — voir section 10, point 5. Les deux coexistent : l'identifiant pérenne sert à relier les versions dans le temps même si le fichier change de nom ou de projet ; le nom de fichier sert à la traçabilité humaine directe, y compris hors de l'application. |
| 22 | | 23 | |
| 23 | ## 4. Formats et pérennité des fichiers | 24 | ## 4. Formats et pérennité des fichiers |
| 24 | | 25 | |
| @@ -83,26 +84,28 @@ Séquence retenue : |
| 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 | - 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 | - 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 | 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 | +4. **Titre et nom de dossier du projet** 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 | - 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 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 | - 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 | - 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 | + - 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 | +5. **Renommage des fichiers** une fois le titre du projet choisi, juste avant le push vers l'archive (le fichier arrive donc déjà sous son nom définitif) : chaque RAW est renommé en `date_titre_nomOrigine.ext`, en conservant le nom d'origine donné par l'appareil en suffixe (ex. `RD1234.RAF` → `2026-09-01_Paris_RD1234.RAF`). Ça donne un nom de fichier auto-descriptif, lisible même en dehors de l'application, tout en gardant la traçabilité de l'ordre de prise de vue au sein d'un même boîtier. |
| 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 | + - **Fichiers associés** : tout fichier partageant le même nom de base que le RAW (JPEG en mode RAW+JPEG, sidecar XMP/DOP) est renommé en même temps et de façon synchronisée, pour ne pas casser l'appariement. |
| 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 | + - **Désambiguïsation entre boîtiers** : le compteur de nom de fichier est propre à chaque appareil, donc deux boîtiers différents (ou le même après un reset) peuvent produire le même nom d'origine. Utiliser en priorité le tag EXIF standard **BodySerialNumber** (`0xA431`, introduit par Exif 2.3) quand il est présent et exploitable (non vide, non valeur placeholder) pour distinguer les sources et ajouter un élément disambiguant seulement en cas de collision réelle (détectée par comparaison de checksum, pas juste par nom identique). Ce champ n'est pas garanti sur tous les boîtiers : fiable chez Canon et Nikon sur la plupart des modèles récents, inconsistant chez Sony, variable chez Fujifilm/Panasonic/Olympus selon le modèle. Repli quand le champ est absent ou vide : demander à l'utilisateur d'étiqueter la source (carte/boîtier) au moment de l'import plutôt que de dépendre uniquement de l'EXIF. |
| | 96 | + - **Ordre de prise de vue** : le nom d'origine en suffixe ne garantit l'ordre chronologique qu'au sein d'un même appareil. Pour un tri fiable entre plusieurs boîtiers dans un même projet, s'appuyer sur la date EXIF (déjà lue à l'étape 2), pas sur un tri alphabétique du nom de fichier renommé. |
| | 97 | +6. Une fois le(s) dossier(s) projet finalisé(s) et les fichiers renommé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 | | 98 | |
| 96 | ## Pistes de fonctionnalités pour Régine | 99 | ## Pistes de fonctionnalités pour Régine |
| 97 | | 100 | |
| 98 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. | 101 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. |
| 99 | -- Identifiant pérenne par photo, indépendant du nom de fichier. | 102 | +- Identifiant pérenne par photo, indépendant du nom de fichier, complémentaire au nom de fichier lisible défini à l'import. |
| 100 | - Notion de fichier maître vs dérivés. | 103 | - Notion de fichier maître vs dérivés. |
| 101 | - Détection de doublons / vérification d'intégrité par checksum. | 104 | - Détection de doublons / vérification d'intégrité par checksum. |
| 102 | - Gestion de niveaux de sélection (brut / sélection / édition finale). | 105 | - Gestion de niveaux de sélection (brut / sélection / édition finale). |
| 103 | - Champs de droits/licence par photo ou par lot. | 106 | - Champs de droits/licence par photo ou par lot. |
| 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. | 107 | - 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. | 108 | +- 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, renommage final `date_titre_nomOrigine` avec désambiguïsation par numéro de série de boîtier (EXIF BodySerialNumber) ou étiquetage manuel en repli — cf. section 10. |
| 106 | | 109 | |
| 107 | ## Sources | 110 | ## Sources |
| 108 | | 111 | |
| @@ -112,3 +115,4 @@ Séquence retenue : |
| 112 | - [Metadata Standards and Tools for Digital Photography — Library of Congress](https://www.digitalpreservation.gov/partners/asmp.html) | 115 | - [Metadata Standards and Tools for Digital Photography — Library of Congress](https://www.digitalpreservation.gov/partners/asmp.html) |
| 113 | - [3-2-1 Backup Rule — Permanent.org](https://www.permanent.org/blog/the-3-2-1-backup-rule/) | 116 | - [3-2-1 Backup Rule — Permanent.org](https://www.permanent.org/blog/the-3-2-1-backup-rule/) |
| 114 | - [Negatives and Transparencies storage — U.S. National Archives](https://www.archives.gov/preservation/storage/negatives-transparencies.html) | 117 | - [Negatives and Transparencies storage — U.S. National Archives](https://www.archives.gov/preservation/storage/negatives-transparencies.html) |
| | 118 | +- [Camera serial numbers — the EXIF fields that link photos to a specific body](https://exifviewer.com/blog/camera-serial-numbers-what-are-they-all-about) |