| @@ -19,18 +19,20 @@ 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 | +- Complémentaire à ça, le nom de fichier archivé suit désormais une convention lisible qui encode la provenance (projet/date) — voir section 10, point 6. 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. |
| 23 | | 23 | |
| 24 | ## 4. Formats et pérennité des fichiers | 24 | ## 4. Formats et pérennité des fichiers |
| 25 | | 25 | |
| 26 | - Distinction fichier maître (RAW ou TIFF non compressé, jamais modifié) vs dérivés de diffusion (JPEG, versions web). | 26 | - Distinction fichier maître (RAW ou TIFF non compressé, jamais modifié) vs dérivés de diffusion (JPEG, versions web). |
| 27 | - Préférence pour des formats ouverts et documentés plutôt que propriétaires. | 27 | - Préférence pour des formats ouverts et documentés plutôt que propriétaires. |
| 28 | - Migrations périodiques planifiées quand un format devient obsolète. | 28 | - Migrations périodiques planifiées quand un format devient obsolète. |
| | 29 | +- **Nuance importante par format, cf. section 12** : cette règle "jamais modifié" tient nativement pour les RAW propriétaires (RAF, CR2, NEF, ARW...), mais pas pour le DNG ni pour les masters TIFF/JPEG, que les outils d'édition courants (Lightroom, DxO PhotoLab) peuvent réécrire pour les métadonnées sans toucher aux pixels. |
| 29 | | 30 | |
| 30 | ## 5. Sauvegarde et intégrité | 31 | ## 5. Sauvegarde et intégrité |
| 31 | | 32 | |
| 32 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. | 33 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. |
| 33 | - Vérification d'intégrité par **checksums** pour détecter la corruption silencieuse dans le temps. | 34 | - Vérification d'intégrité par **checksums** pour détecter la corruption silencieuse dans le temps. |
| | 35 | +- Un checksum ne fait que détecter une corruption, il ne la répare pas : la récupération dépend soit d'une copie saine (règle 3-2-1), soit d'un mécanisme de redondance/réparation dédié — cf. section 12. |
| 34 | | 36 | |
| 35 | ## 6. Conservation physique (négatifs/tirages argentiques) | 37 | ## 6. Conservation physique (négatifs/tirages argentiques) |
| 36 | | 38 | |
| @@ -60,8 +62,8 @@ Déroulé : |
| 60 | - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps. | 62 | - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps. |
| 61 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : | 63 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : |
| 62 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. | 64 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. |
| 63 | - - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. | 65 | + - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 12), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.** |
| 64 | - - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. | 66 | + - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier de projet entier (ex. transformation d'un projet simple en sous-projet, section 10) — un déplacement massif de fichiers à hash inchangé, pas un cas à part.** |
| 65 | - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive. | 67 | - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive. |
| 66 | - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local). | 68 | - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local). |
| 67 | - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS. | 69 | - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS. |
| @@ -75,7 +77,7 @@ Points à anticiper pour l'implémentation : |
| 75 | | 77 | |
| 76 | ## 10. Import depuis une carte mémoire | 78 | ## 10. Import depuis une carte mémoire |
| 77 | | 79 | |
| 78 | -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). | 80 | +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). Inclut le cas d'un voyage en plusieurs étapes (ex. plusieurs villes), où les imports successifs doivent pouvoir s'organiser en projet parent + sous-projets plutôt qu'en projets indépendants. |
| 79 | | 81 | |
| 80 | Séquence retenue : | 82 | Séquence retenue : |
| 81 | | 83 | |
| @@ -83,18 +85,26 @@ Séquence retenue : |
| 83 | 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. | 85 | 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. |
| 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é. | 86 | - 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é. |
| 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. | 87 | - 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. |
| 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. | 88 | +3. **Proposition de découpage en un ou plusieurs groupes** à partir de cette répartition jour par jour. Par défaut, un seul groupe pour toute la plage contiguë détectée, mais l'utilisateur doit pouvoir détacher un ou plusieurs jours (cas type : une semaine de vacances avec un anniversaire au milieu, à isoler à part). 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. |
| 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 : | 89 | +4. **Destination de chaque groupe résultant** : pour chaque groupe issu du découpage, Régine demande explicitement où il doit aller, parmi quatre cas — posée à chaque import, sans état "voyage en cours" retenu en mémoire d'une fois sur l'autre : |
| 88 | - - un jour unique : `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`) | 90 | + - **Nouveau projet simple** : comportement par défaut, structure à un seul niveau. |
| 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) | 91 | + - **Nouveau sous-projet dans un projet parent existant** : cas d'un voyage déjà en plusieurs étapes — Régine liste les projets existants pour que l'utilisateur choisisse le parent. |
| 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) | 92 | + - **Fusion dans un projet existant** : ajout direct des fichiers à un projet déjà là, sans nouveau sous-dossier — cas de deux cartes mémoire (deux boîtiers, ou une carte de secours) couvrant la même sortie. Réutilise directement la désambiguïsation par `BodySerialNumber`/étiquetage manuel et la détection de doublons par checksum déjà prévues (point 2 ci-dessus et section 10 point 6). Si le projet ciblé est déjà archivé sur le NAS (pas seulement local), la fusion implique d'abord un checkout de ce projet (section 9) pour y intégrer les nouveaux fichiers avant de repousser l'ensemble via la réconciliation habituelle. |
| 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. | 93 | + - **Nouveau projet parent avec sa première étape** : à choisir dès le tout premier import d'un ensemble qu'on sait multi-parties (ex. un voyage) — Régine crée directement la structure à deux niveaux (dossier parent + premier sous-dossier enfant) dès cet import, plutôt qu'un projet plat qu'il faudrait restructurer plus tard. |
| 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. | 94 | + - Pour proposer un choix pertinent (2ᵉ et 3ᵉ cas), Régine liste les projets existants aussi bien en local (espace de travail) que dans l'archive NAS (recherche par titre/date proche) — pas seulement une liste éphémère en mémoire de session. |
| 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. | 95 | +5. **Titre et nom de dossier** demandé pour chaque groupe, nettoyé pour servir de nom de dossier (espaces → underscores, interdiction des caractères invalides `/ \ : * ? " < >`), puis combiné à la plage de dates : |
| | 96 | + - projet simple ou étape d'un voyage : un jour unique `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`) ou, pour une étape de voyage, `YYYY-MM-DD_Titre_Lieu` (ex. `2026-08-12_Montenegro_Kotor`) ; une plage dans le même mois `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace`) ; une plage à cheval sur deux mois/années en forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois). |
| | 97 | + - projet parent (voyage) : granularité mois, `YYYY-MM_Titre` (ex. `2026-08_Montenegro`) — la date de fin n'est pas connue au moment du premier import. Peut être affiné a posteriori avec la plage réelle une fois le voyage terminé, sans obligation (le nom du dossier n'a pas besoin d'être une description exacte). |
| | 98 | + - le lieu (ville, étape) est saisi librement par l'utilisateur, avec suggestion automatique optionnelle si des coordonnées GPS sont présentes en EXIF (les smartphones en ont, la plupart des boîtiers dédiés non) — en simple suggestion, jamais imposée, même prudence que pour la détection de jours particuliers au point 3. |
| | 99 | + - si un jour est extrait du milieu d'une plage contiguë, le groupe restant garde le nom de la plage d'origine plutôt que de recalculer un nom qui ne refléterait que les jours effectivement inclus. |
| | 100 | + - vérification de collision avant de créer le dossier final : si un nom identique existe déjà, proposer un suffixe ou demander confirmation plutôt que d'écraser. |
| | 101 | +6. **Renommage des fichiers** une fois le titre 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. |
| 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. | 102 | - **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. |
| 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. | 103 | - **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é. | 104 | - **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). | 105 | +7. Une fois le(s) dossier(s) 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). |
| | 106 | + |
| | 107 | +**Transformer un projet existant en sous-projet, a posteriori.** Si l'utilisateur n'a pas anticipé qu'un import allait devenir le début d'un voyage à plusieurs étapes (4ᵉ cas du point 4), rien n'empêche de corriger après coup : déplacer le dossier du projet existant à l'intérieur d'un nouveau (ou d'un autre) projet parent, en renommant si besoin le dossier et ses fichiers. C'est une opération légère, pas une limitation à contourner : le déplacement et le renommage ne changent aucun octet, donc les checksums restent identiques (cas déjà couvert par la détection de déplacement par hash, section 9) ; les side files (XMP/DOP) suivent leur fichier associé puisqu'ils sont déjà renommés de façon synchronisée (point 6 ci-dessus) ; et l'identifiant pérenne (section 3), pensé justement pour être indépendant du chemin et du nom de fichier, reste inchangé tout du long. Si le projet à transformer est déjà archivé, l'opération passe par le cycle checkout/réconciliation habituel plutôt que par une modification directe du NAS hors de Régine. |
| 98 | | 108 | |
| 99 | ## 11. Structure d'un projet, sélection et déchets évidents | 109 | ## 11. Structure d'un projet, sélection et déchets évidents |
| 100 | | 110 | |
| @@ -110,7 +120,7 @@ Ce découpage par format plutôt que par statut (sélection/reste) remplace le d |
| 110 | | 120 | |
| 111 | **La promotion vers la racine est une action manuelle de l'utilisateur dans son outil d'édition (DxO ou autre), pas une décision automatique de Régine.** Le rôle de Régine se limite à détecter ce déplacement à la réconciliation (section 9) : un fichier retrouvé à un autre chemin avec le même hash de contenu est traité comme le cas "renommage/déplacement détecté par le contenu" déjà prévu, qu'il s'agisse d'une promotion vers la racine, d'un retour en arrière, ou d'un déplacement entre dossiers de format. Aucun mécanisme supplémentaire à construire pour ça. | 121 | **La promotion vers la racine est une action manuelle de l'utilisateur dans son outil d'édition (DxO ou autre), pas une décision automatique de Régine.** Le rôle de Régine se limite à détecter ce déplacement à la réconciliation (section 9) : un fichier retrouvé à un autre chemin avec le même hash de contenu est traité comme le cas "renommage/déplacement détecté par le contenu" déjà prévu, qu'il s'agisse d'une promotion vers la racine, d'un retour en arrière, ou d'un déplacement entre dossiers de format. Aucun mécanisme supplémentaire à construire pour ça. |
| 112 | | 122 | |
| 113 | -L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de reposer sur le nom de fichier identique hors extension, garanti par la convention de renommage à l'import (section 10, point 5) — même si RAW et JPEG ne sont jamais dans le même dossier. | 123 | +L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de reposer sur le nom de fichier identique hors extension, garanti par la convention de renommage à l'import (section 10, point 6) — même si RAW et JPEG ne sont jamais dans le même dossier. |
| 114 | | 124 | |
| 115 | **Deux catégories de fichiers non retenus, deux traitements différents.** Ne pas tout mettre dans le même panier : | 125 | **Deux catégories de fichiers non retenus, deux traitements différents.** Ne pas tout mettre dans le même panier : |
| 116 | | 126 | |
| @@ -124,6 +134,36 @@ L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de |
| 124 | - Pas d'association visuelle entre un RAW et son JPEG jumeau (mode RAW+JPEG) : les deux apparaissent comme deux entrées séparées dans la liste, ce qui pousse à en supprimer un juste pour désencombrer l'affichage. Objectif pour Régine : regrouper une paire RAW+JPEG comme une seule entrée à l'écran, même si elles vivent dans des dossiers différents. | 134 | - Pas d'association visuelle entre un RAW et son JPEG jumeau (mode RAW+JPEG) : les deux apparaissent comme deux entrées séparées dans la liste, ce qui pousse à en supprimer un juste pour désencombrer l'affichage. Objectif pour Régine : regrouper une paire RAW+JPEG comme une seule entrée à l'écran, même si elles vivent dans des dossiers différents. |
| 125 | - Navigation limitée au dossier courant, pas de vue combinée racine + sous-dossiers. Objectif pour Régine : permettre une vue multi-dossiers d'un même projet. | 135 | - Navigation limitée au dossier courant, pas de vue combinée racine + sous-dossiers. Objectif pour Régine : permettre une vue multi-dossiers d'un même projet. |
| 126 | | 136 | |
| | 137 | +## 12. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment |
| | 138 | + |
| | 139 | +Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la règle "le fichier maître n'est jamais modifié" (section 4) ne se comporte pas de la même façon selon le format. |
| | 140 | + |
| | 141 | +**RAW propriétaires (RAF, CR2, NEF, ARW...)** : ni Lightroom Classic ni DxO PhotoLab ne réécrivent le fichier RAW original. Les réglages de développement et les métadonnées vont systématiquement dans des sidecars séparés — `.xmp` (+ `.acr` pour les réglages avancés récents type masques/débruitage IA) côté Lightroom, `.dop` (réglages) + `.xmp` (métadonnées) côté DxO. Le hash du fichier entier reste donc un indicateur fiable d'intégrité pour ces formats : un changement de hash = anomalie réelle. |
| | 142 | + |
| | 143 | +**Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF/BMP :** |
| | 144 | + |
| | 145 | +- **DNG** : traité différemment des autres RAW par Lightroom, qui écrit les métadonnées et réglages _directement dans le fichier DNG_ (pas de sidecar par défaut). Le hash du fichier entier change donc à chaque édition de métadonnées, sans corruption ni changement des pixels. |
| | 146 | +- **TIFF/JPEG** (masters de scan section 11, ou JPEG promu à la racine) : DxO indique explicitement que la "sanctuarisation" du fichier original ne s'applique pas aux fichiers RVB (JPG, TIFF, DNG) — l'écriture de métadonnées peut se faire directement dans le fichier. |
| | 147 | + |
| | 148 | +**Conséquence pour le hash de réconciliation (section 9)** : pour DNG/TIFF/JPEG, un hash sur le fichier entier ne permet plus de distinguer une édition de métadonnées légitime d'une vraie corruption (ex. erreur d'écriture disque). Il faut un hash portant uniquement sur les données image (pixels), stable à travers les éditions de métadonnées : |
| | 149 | + |
| | 150 | +- **Le DNG a un tag natif prévu pour ça** : `RawDataUniqueID` (tag TIFF 0xC65D), défini dans la spec Adobe DNG comme un identifiant dérivé des données image, indépendant des métadonnées. À vérifier au cas par cas : tous les boîtiers ne le renseignent pas de façon fiable. Test rapide : `exiftool -RawDataUniqueID -ImageUniqueID fichier.dng`. |
| | 151 | +- **Solution plus robuste et indépendante du boîtier : `ImageDataHash` d'ExifTool.** Calcule un hash (MD5/SHA256/SHA512) sur les seules données image, en excluant les métadonnées. Pas activé par défaut, nécessite l'option API `ImageHashType` : |
| | 152 | + ``` |
| | 153 | + exiftool -api ImageHashType=SHA256 -ImageDataHash fichier.dng |
| | 154 | + ``` |
| | 155 | + Utilisé dans ce but précis (détection de corruption indépendamment des éditions de métadonnées) par le projet PhotoStructure, dont l'architecture d'archivage recoupe largement celle de Régine. |
| | 156 | + |
| | 157 | +**Révision proposée pour le manifeste et la réconciliation (section 9)** : stocker, pour les formats DNG/TIFF/JPEG, un hash image-only (`ImageDataHash`) en plus (ou à la place) du hash fichier entier. À la réconciliation : hash fichier changé + hash image-only inchangé → édition de métadonnées légitime, archivable normalement ; hash image-only changé → vraie anomalie, jamais archivé silencieusement (même traitement que pour un RAW propriétaire aujourd'hui). |
| | 158 | + |
| | 159 | +**Lacune identifiée dans le design actuel** : le workflow de la section 9 ne vérifie les hash qu'au moment d'un checkout/réarchivage. Ça ne détecte pas une corruption survenant plus tard, pendant que l'archive dort sur le NAS sans qu'on y touche (bit rot classique). Il manque une tâche de **vérification périodique** (scrub), indépendante de tout checkout, qui recalcule et compare les hash de l'archive à intervalle régulier (ex. mensuel). |
| | 160 | + |
| | 161 | +**Détection vs réparation** : un hash (quel qu'il soit) détecte une corruption, il ne la répare pas. Options pour la réparation, à documenter/choisir séparément : |
| | 162 | + |
| | 163 | +- Restaurer depuis une copie saine (règle 3-2-1, section 5). |
| | 164 | +- Fichiers de parité **PAR2** (Parchive) stockés à côté du master : permettent de réparer une corruption partielle sans disposer d'une deuxième copie complète du fichier. |
| | 165 | +- Système de fichiers à checksums auto-réparants (**ZFS**, **Btrfs**) avec redondance (miroir/RAID) : détection et réparation automatiques à la lecture, au niveau du NAS plutôt que de l'application. |
| | 166 | + |
| 127 | ## Pistes de fonctionnalités pour Régine | 167 | ## Pistes de fonctionnalités pour Régine |
| 128 | | 168 | |
| 129 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. | 169 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. |
| @@ -133,9 +173,10 @@ L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de |
| 133 | - Gestion de niveaux de sélection (brut / sélection / édition finale). | 173 | - Gestion de niveaux de sélection (brut / sélection / édition finale). |
| 134 | - Champs de droits/licence par photo ou par lot. | 174 | - Champs de droits/licence par photo ou par lot. |
| 135 | - 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. | 175 | - 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. |
| 136 | -- 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. | 176 | +- Import carte mémoire avec quatre destinations possibles à chaque fois (nouveau projet simple, nouveau sous-projet d'un parent existant, fusion dans un projet existant, nouveau projet parent avec sa première étape), recherche des projets candidats en local et dans l'archive, structure voyage (parent `YYYY-MM_Titre` / étapes `YYYY-MM-DD_Titre_Lieu`), et transformation a posteriori d'un projet simple en sous-projet — cf. section 10. |
| 137 | - Structure de projet par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, `bmp/`, extensible à d'autres formats) avec sélection à la racine (promotion manuelle, par fichier), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF/BMP — cf. section 11. | 177 | - Structure de projet par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, `bmp/`, extensible à d'autres formats) avec sélection à la racine (promotion manuelle, par fichier), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF/BMP — cf. section 11. |
| 138 | - Interface de tri/culling propre à Régine : association visuelle RAW+JPEG même dans des dossiers différents, navigation multi-dossiers d'un même projet, checkout partiel (`jpeg/` seul) pour un tri rapide sans toucher aux RAW archivés, suppression de déchets évidents via la confirmation de réconciliation — cf. section 11. | 178 | - Interface de tri/culling propre à Régine : association visuelle RAW+JPEG même dans des dossiers différents, navigation multi-dossiers d'un même projet, checkout partiel (`jpeg/` seul) pour un tri rapide sans toucher aux RAW archivés, suppression de déchets évidents via la confirmation de réconciliation — cf. section 11. |
| | 179 | +- Hash d'intégrité à deux niveaux (fichier entier + image-only via ExifTool `ImageDataHash`) pour distinguer édition de métadonnées et vraie corruption sur DNG/TIFF/JPEG, plus une tâche de vérification périodique (scrub) indépendante du checkout — cf. section 12. |
| 139 | | 180 | |
| 140 | ## Sources | 181 | ## Sources |
| 141 | | 182 | |
| @@ -146,3 +187,9 @@ L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de |
| 146 | - [3-2-1 Backup Rule — Permanent.org](https://www.permanent.org/blog/the-3-2-1-backup-rule/) | 187 | - [3-2-1 Backup Rule — Permanent.org](https://www.permanent.org/blog/the-3-2-1-backup-rule/) |
| 147 | - [Negatives and Transparencies storage — U.S. National Archives](https://www.archives.gov/preservation/storage/negatives-transparencies.html) | 188 | - [Negatives and Transparencies storage — U.S. National Archives](https://www.archives.gov/preservation/storage/negatives-transparencies.html) |
| 148 | - [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) | 189 | - [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) |
| | 190 | +- [Lightroom Classic — Save metadata to external sidecar files (Adobe)](https://helpx.adobe.com/lightroom-classic/help/create-xmp-acr-files.html) |
| | 191 | +- [DxO Forum — Exact rules for the creation and use of sidecar files](https://forum.dxo.com/t/exact-rules-for-the-creation-and-use-of-sidecar-files/36580) |
| | 192 | +- [DNG Confusion from an Experienced User — Lightroom Queen Forums](https://www.lightroomqueen.com/community/threads/dng-confusion-from-an-experienced-user.45702/) |
| | 193 | +- [Digital Negative (DNG) Specification 1.6.0.0 — Adobe](https://paulbourke.net/dataformats/dng/dng_spec_1_6_0_0.pdf) |
| | 194 | +- [ExifTool ImageDataHash — exiftool-vendored.js (PhotoStructure)](https://github.com/photostructure/exiftool-vendored.js/blob/main/src/ImageDataHashTag.ts) |
| | 195 | +- [Image::ExifTool — API options incl. ImageHashType — metacpan.org](https://metacpan.org/dist/Image-ExifTool/view/lib/Image/ExifTool.pod) |