| @@ -20,6 +20,7 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections |
| 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 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. | 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 | +- **Stockage retenu, cf. section 14** : l'identifiant pérenne doit être écrit dans les métadonnées du fichier lui-même (XMP), pas seulement dans la base SQLite de Régine — utile en particulier pour relier un export/rendu dérivé à son fichier maître, puisque cette dérivée a par nature un contenu (et donc un checksum) différent du maître. **À vérifier avant de construire quoi que ce soit de maison, cf. section 14** : un standard existant (XMP Media Management, `DerivedFrom`/`OriginalDocumentID`) pourrait déjà couvrir ce besoin sans que Régine ait à inventer son propre champ. |
| 23 | | 24 | |
| 24 | ## 4. Formats et pérennité des fichiers | 25 | ## 4. Formats et pérennité des fichiers |
| 25 | | 26 | |
| @@ -58,24 +59,21 @@ Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) |
| 58 | | 59 | |
| 59 | Déroulé : | 60 | Déroulé : |
| 60 | | 61 | |
| 61 | -- **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3). | 62 | +- **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3). **Ce manifeste n'est plus un objet jetable propre au checkout : il correspond à un instantané de la base persistante décrite en section 13, qui vit en permanence à côté du projet sur le NAS. Le checkout porte toujours sur le projet complet (le projet parent avec tous ses sous-projets, s'il y en a) — cf. section 13, un sous-projet ne se checkout jamais isolément.** |
| 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. | 63 | - **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. |
| 63 | - - **Restauration à la demande.** À tout moment de cette phase, sans attendre le "point avant archive", l'utilisateur peut demander explicitement à Régine de restaurer un fichier qu'il vient d'effacer localement (erreur de manipulation, changement d'avis). Ce n'est pas une fonctionnalité séparée : c'est la même commande de restauration que celle déclenchée par un refus de suppression à la réconciliation (voir plus bas), rendue disponible en continu pendant l'édition plutôt que seulement au moment de la validation finale. | | |
| 64 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : | 64 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : |
| 65 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. | 65 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. |
| 66 | - 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.** | 66 | - 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.** |
| 67 | - - 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.** | 67 | + - 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), et la promotion d'une photo depuis la racine d'un sous-projet vers la racine du projet parent (planche-contact globale, section 11) — un déplacement de fichier à hash inchangé, pas un cas à part.** |
| 68 | - - hash du manifeste absent de la copie de travail → suppression candidate → jamais propagée automatiquement ; listée explicitement (pas noyée dans un compte global) au "point avant archive", avec confirmation explicite requise fichier par fichier avant de toucher à l'archive. | 68 | + - 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. |
| 69 | - 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). | 69 | - 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). |
| 70 | - 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. | 70 | - 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. |
| 71 | -- **Restauration, le mécanisme commun.** Restaurer un fichier consiste à le retrouver dans l'archive NAS via son identifiant pérenne (cf. section 3) — encore intacte tant que rien n'a été poussé — et à le recopier dans la copie de travail locale, avec vérification checksum comme pour tout autre transfert (section 5). Deux déclencheurs pour la même commande : à la demande de l'utilisateur pendant l'édition (voir "Travail local" ci-dessus), ou automatiquement quand il refuse une suppression candidate au "point avant archive" (voir ci-dessous). Dans les deux cas, le fichier restauré n'est plus une suppression candidate : il retombe dans le cas normal (hash inchangé). | | |
| 72 | -- **Refus d'une suppression, fichier par fichier.** Au "point avant archive", chaque suppression candidate se valide indépendamment : accepter, ou refuser. Un refus déclenche la restauration décrite ci-dessus, pas un simple retrait de la liste. L'upload vers l'archive ne démarre qu'une fois que chaque suppression candidate a été traitée, soit acceptée soit restaurée — jamais avec des suppressions encore en attente d'arbitrage. | | |
| 73 | | 71 | |
| 74 | Points à anticiper pour l'implémentation : | 72 | Points à anticiper pour l'implémentation : |
| 75 | | 73 | |
| 76 | - Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go). | 74 | - Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go). |
| 77 | - Temps de transfert réseau au moment du checkout. | 75 | - Temps de transfert réseau au moment du checkout. |
| 78 | -- 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. | 76 | +- 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. **Le travail à plusieurs (verrouillage fin, édition concurrente de deux sous-projets d'un même projet parent) est mis de côté pour le moment — cf. section 13.** |
| 79 | - 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. | 77 | - 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. |
| 80 | | 78 | |
| 81 | ## 10. Import depuis une carte mémoire | 79 | ## 10. Import depuis une carte mémoire |
| @@ -112,7 +110,7 @@ Séquence retenue : |
| 112 | - **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é. | 110 | - **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é. |
| 113 | 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). | 111 | 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). |
| 114 | | 112 | |
| 115 | -**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. | 113 | +**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. **Si le projet devenu sous-projet avait déjà sa propre base de checksums (section 13), ses lignes sont absorbées dans la base du projet parent au même moment — cf. section 13 pour le détail.** |
| 116 | | 114 | |
| 117 | ## 11. Structure d'un projet, sélection et déchets évidents | 115 | ## 11. Structure d'un projet, sélection et déchets évidents |
| 118 | | 116 | |
| @@ -124,6 +122,8 @@ Structure retenue pour un projet (après plusieurs itérations) : |
| 124 | | 122 | |
| 125 | Ce découpage par format plutôt que par statut (sélection/reste) remplace le dossier "autres" envisagé précédemment : ce qui n'est pas promu à la racine reste simplement dans son dossier de format. | 123 | Ce découpage par format plutôt que par statut (sélection/reste) remplace le dossier "autres" envisagé précédemment : ce qui n'est pas promu à la racine reste simplement dans son dossier de format. |
| 126 | | 124 | |
| | 125 | +**Un projet parent est un projet comme les autres, avec sa propre racine.** Un sous-projet (étape d'un voyage) a sa propre structure complète (dossiers de format + sa propre racine, sélection au niveau de l'étape). Le projet parent a en plus sa propre racine à lui, qui sert de planche-contact globale sur l'ensemble du voyage : une photo peut être promue une deuxième fois, de la racine de son étape vers la racine du projet parent, pour apparaître dans cette vue d'ensemble. **Promotion en deux temps** (racine de l'étape, puis racine du voyage), pas un raccourci direct depuis le dossier de format de l'étape — deux gestes distincts, correspondant à deux niveaux de sélection réels (la meilleure photo de l'étape, puis les meilleures du voyage entier). Techniquement, ce deuxième déplacement est un cas de plus couvert par la détection de déplacement par hash déjà en place (section 9), rien de spécifique à construire. |
| | 126 | + |
| 127 | **Cas des scans TIFF** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. | 127 | **Cas des scans TIFF** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. |
| 128 | | 128 | |
| 129 | **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. | 129 | **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. |
| @@ -135,7 +135,7 @@ L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de |
| 135 | - **Déchets évidents** (test d'exposition, déclenchement accidentel, photo des pieds...) : suppression légitime, tous formats compris, avant même le tri par format. Ça ne contredit pas le principe de fichier maître jamais modifié silencieusement (section 4) : la suppression passe par la confirmation explicite déjà prévue à l'étape de réconciliation (section 9) — c'est exactement l'usage prévu de cette étape, pas une entorse à la règle. | 135 | - **Déchets évidents** (test d'exposition, déclenchement accidentel, photo des pieds...) : suppression légitime, tous formats compris, avant même le tri par format. Ça ne contredit pas le principe de fichier maître jamais modifié silencieusement (section 4) : la suppression passe par la confirmation explicite déjà prévue à l'étape de réconciliation (section 9) — c'est exactement l'usage prévu de cette étape, pas une entorse à la règle. |
| 136 | - **Captures correctement prises mais non sélectionnées** (pas les meilleures, ni des déchets) : jamais supprimées ; elles restent simplement dans leur dossier de format, non promues à la racine. | 136 | - **Captures correctement prises mais non sélectionnées** (pas les meilleures, ni des déchets) : jamais supprimées ; elles restent simplement dans leur dossier de format, non promues à la racine. |
| 137 | | 137 | |
| 138 | -**Checkout partiel pour aller vite.** Pour un usage type vacances où la vitesse prime, Régine peut ne faire sortir que le dossier `jpeg/` (et la racine) dans l'espace de travail local, sans le `raw/`, pour un tri/traitement rapide dans l'outil du moment. Les RAW correspondants restent dans l'archive, non modifiés, récupérables séparément si un cas se révèle finalement difficile à traiter. Cette structure par format rend ce checkout partiel immédiat (un dossier entier à exclure), plus simple qu'avec un tri par statut où RAW et JPEG étaient mélangés. | 138 | +**Checkout partiel pour aller vite.** Pour un usage type vacances où la vitesse prime, Régine peut ne faire sortir que le dossier `jpeg/` (et la racine) dans l'espace de travail local, sans le `raw/`, pour un tri/traitement rapide dans l'outil du moment. Les RAW correspondants restent dans l'archive, non modifiés, récupérables séparément si un cas se révèle finalement difficile à traiter. Cette structure par format rend ce checkout partiel immédiat (un dossier entier à exclure), plus simple qu'avec un tri par statut où RAW et JPEG étaient mélangés. **Ce "partiel" porte sur les formats à l'intérieur d'un projet complet, pas sur un sous-projet isolé du reste — cf. section 13, on ne checkout jamais un seul sous-projet sans son projet parent.** |
| 139 | | 139 | |
| 140 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** | 140 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** |
| 141 | | 141 | |
| @@ -148,6 +148,8 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 148 | | 148 | |
| 149 | **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. | 149 | **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. |
| 150 | | 150 | |
| | 151 | +**Point clé, à garder en tête pour toute la suite : le développement RAW est non destructif par nature.** Recadrage, exposition, étalonnage — tout ça reste une "recette" de rendu stockée en métadonnées (sidecar ou embarquées), jamais appliquée aux données image elles-mêmes. Ça vaut aussi bien pour un RAW propriétaire que pour un DNG, et pour un JPEG/TIFF traité en non destructif dans DxO/Lightroom (par opposition à un écrasement direct du fichier, qui n'est jamais la façon dont Régine ou ces outils fonctionnent par défaut). Conséquence directe : le fichier maître garde le même contenu pixel — et donc peut être suivi par checksum indéfiniment — quel que soit le nombre de fois où il est retravaillé, tant que ce travail passe par un sidecar/des métadonnées et non par une réécriture directe des pixels. |
| | 152 | + |
| 151 | **Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :** | 153 | **Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :** |
| 152 | | 154 | |
| 153 | - **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. | 155 | - **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. |
| @@ -160,11 +162,11 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 160 | ``` | 162 | ``` |
| 161 | exiftool -api ImageHashType=SHA256 -ImageDataHash fichier.dng | 163 | exiftool -api ImageHashType=SHA256 -ImageDataHash fichier.dng |
| 162 | ``` | 164 | ``` |
| 163 | - 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. | 165 | + 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. **C'est aussi le hash qui permet de suivre un DNG par checksum sur la durée, retouche comprise (section 14) : il reste stable tant que seules les métadonnées/réglages changent.** |
| 164 | | 166 | |
| 165 | **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). | 167 | **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). |
| 166 | | 168 | |
| 167 | -**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). | 169 | +**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). **Cette tâche a besoin d'un manifeste persistant sur l'archive plutôt qu'un manifeste éphémère créé à chaque checkout — cf. section 13.** |
| 168 | | 170 | |
| 169 | **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 : | 171 | **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 : |
| 170 | | 172 | |
| @@ -172,10 +174,79 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 172 | - 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. | 174 | - 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. |
| 173 | - 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. | 175 | - 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. |
| 174 | | 176 | |
| | 177 | +## 13. Manifeste persistant par projet et compatibilité de format entre versions de Régine |
| | 178 | + |
| | 179 | +Point de départ (2026-09-11) : le manifeste décrit en section 9 n'existait jusqu'ici que comme un instantané pris au moment d'un checkout, recréé à chaque fois plutôt que conservé. Deux besoins poussent à le rendre persistant, stocké en permanence à côté de chaque projet sur le NAS : la vérification périodique (scrub, section 12), qui a besoin d'un état de référence stable dans le temps et pas seulement au moment d'une édition ; et la nécessité qu'une version ancienne de Régine ne puisse pas ouvrir/écrire un projet dont le format a évolué depuis, pour éviter une corruption silencieuse par mécompréhension du format. |
| | 180 | + |
| | 181 | +**Choix de format : SQLite plutôt qu'un fichier JSON pour les checksums.** Un JSON plat contenant les checksums de tout un projet (potentiellement des milliers de fichiers) et réécrit intégralement à chaque réconciliation est vulnérable à une coupure (crash, perte d'alimentation) en plein milieu de l'écriture — un comble pour un mécanisme censé protéger contre la corruption. SQLite écrit de façon transactionnelle : pas d'état intermédiaire corrompu possible. C'est aussi cohérent avec le principe de section 4 ("formats ouverts et documentés plutôt que propriétaires") : la Bibliothèque du Congrès américaine recommande explicitement SQLite comme format de stockage pour l'archivage à long terme (déclaration 2025-2026), et SQLite lui-même documente son usage comme format de fichier applicatif à part entière (transactions, requêtes indexées, un seul fichier auto-suffisant). |
| | 182 | + |
| | 183 | +**La version de format doit vivre dans la base elle-même, pas dans un fichier séparé.** SQLite prévoit exactement ce besoin avec deux pragmas intégrés à l'en-tête du fichier : |
| | 184 | + |
| | 185 | +- `PRAGMA user_version` — un entier libre, à utiliser comme numéro de version du schéma de Régine. |
| | 186 | +- `PRAGMA application_id` — un identifiant numérique enregistré publiquement auprès du projet SQLite pour marquer "ce fichier appartient au format de Régine" (permet à un outil externe, ou à `file`, de reconnaître le format). |
| | 187 | + |
| | 188 | +L'intérêt sur un fichier de version séparé (l'idée initiale d'un `Regine.json` distinct pour la version) : la version et les données qu'elle décrit ne peuvent jamais se désynchroniser, puisqu'elles vivent dans le même fichier, écrit de façon atomique. |
| | 189 | + |
| | 190 | +**Version d'appli vs version de format : deux choses différentes à ne pas confondre.** La version de Régine (numéro de release, change souvent) ne doit pas être le critère de compatibilité — la plupart des mises à jour de l'appli ne toucheront jamais la structure des données sur disque. Le critère doit porter sur un numéro de format qui n'augmente que lorsque la structure change réellement, avec deux niveaux de gravité (à la manière de `core.repositoryformatversion` dans Git, qui bloque uniquement sur les extensions de format inconnues, ou du versionnage interne de SQLite) : |
| | 191 | + |
| | 192 | +- changement additif (nouveau champ optionnel) → une version plus ancienne de Régine peut l'ignorer et continuer à fonctionner normalement ; |
| | 193 | +- changement structurel (renommage, suppression, changement de sens d'un champ, nouvel algorithme de hash) → refus explicite d'ouvrir le projet avec une version de Régine trop ancienne, plutôt qu'une mauvaise interprétation silencieuse. |
| | 194 | + |
| | 195 | +**Migration à anticiper dès la conception, même sans l'implémenter tout de suite.** Le jour où un changement structurel impose ce refus, il faut qu'une version récente de Régine sache mettre à niveau un projet ancien en place. Sans ça, un projet ancien devient lisible par une seule version précise de l'appli — contraire à l'objectif d'archivage long terme de tout le projet. |
| | 196 | + |
| | 197 | +**Portée retenue : une base SQLite unique à la racine du projet principal, couvrant aussi ses sous-projets.** Révision du 2026-09-11 par rapport à la première version de cette section (qui proposait une base par sous-projet, composée à la demande via `ATTACH DATABASE`) : cette première version reposait sur deux hypothèses que Fabien a corrigées entre-temps — |
| | 198 | + |
| | 199 | +- un sous-projet n'est **jamais checké out isolément** : c'est le projet global (parent + sous-projets) qui constitue l'unité de gestion, pas chaque étape individuellement (cf. sections 9 et 11) ; |
| | 200 | +- **le travail à plusieurs (verrouillage fin par sous-projet pour permettre l'édition concurrente de deux étapes) est mis de côté pour le moment**, ce qui retire l'argument principal en faveur de bases séparées. |
| | 201 | + |
| | 202 | +Avec ces deux précisions, une base unique par projet (le projet parent, sous-projets inclus) est le choix le plus simple et le plus cohérent, pour deux raisons supplémentaires : |
| | 203 | + |
| | 204 | +- Le projet parent a sa propre racine, qui sert de planche-contact globale sur l'ensemble du voyage (section 11) : promouvoir une photo de la racine d'une étape vers la racine du projet parent est alors un déplacement de plus, couvert nativement par la détection de renommage/déplacement par hash déjà en place (section 9) — sans base séparée, pas besoin de gérer une transition d'une base à l'autre pour ce geste. |
| | 205 | +- Fusionner les checksums d'un projet devenu sous-projet (section 10) dans la base de son nouveau parent reste une opération bon marché avec SQLite (`ATTACH` de l'ancienne base, `INSERT ... SELECT`, suppression de l'ancien fichier) — un coût ponctuel et transactionnel, pas une migration fragile. |
| | 206 | + |
| | 207 | +La suggestion `ATTACH DATABASE` pour composer plusieurs bases à la demande devient donc inutile dans ce modèle — un seul fichier à interroger. Si le travail à plusieurs est repris plus tard, la question du verrouillage par sous-projet (plutôt que par projet entier) sera à rouvrir à ce moment-là ; ce n'est pas un renoncement définitif, juste une simplification volontaire pour l'instant. |
| | 208 | + |
| | 209 | +**Un petit fichier JSON complémentaire reste utile, mais avec un rôle différent** : pas les checksums, une simple fiche d'identité du projet lisible sans outil (nom, identifiant pérenne, date de création, copie du numéro de format pour un coup d'œil rapide sans ouvrir la base SQLite). À écrire selon la même discipline que tout fichier qui ne doit jamais être observé à moitié écrit : écriture dans un fichier temporaire puis renommage atomique, plutôt que réécriture directe du fichier final. |
| | 210 | + |
| | 211 | +**Un sous-projet garde sa propre base, elle ne fusionne pas dans celle du parent — voir la portée révisée plus haut dans cette section.** |
| | 212 | + |
| | 213 | +## 14. Copie inter-projets pour composer un nouveau projet (livre, sélection thématique) |
| | 214 | + |
| | 215 | +Point de départ (2026-09-11) : au-delà du "Bestof" évoqué comme exemple, le cas général est de piocher dans l'archive pour composer un nouveau projet autonome (un livre, une expo) en **copiant** les fichiers choisis depuis leurs projets d'origine, plutôt qu'en les déplaçant ou en les référençant. Confirmé : ces projets restent des projets séparés et indépendants, pas rattachés les uns aux autres par une hiérarchie parent/sous-projet — le livre est son propre projet. |
| | 216 | + |
| | 217 | +**Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :** |
| | 218 | + |
| | 219 | +- La détection de déplacement par hash (section 9) ne fonctionne qu'à l'intérieur d'un seul projet, entre sa copie de travail et son propre manifeste — elle n'a jamais été prévue pour repérer un fichier traversant deux projets différents. Une référence entre projets ne serait donc de toute façon suivie par aucun mécanisme existant. |
| | 220 | +- Un lien symbolique casse le principe d'auto-suffisance des projets (section 11/13) : il pointe dans le vide si le projet source est déplacé ou renommé. |
| | 221 | +- Un lien physique (hardlink) semble économiser l'espace disque, mais défait justement l'objectif recherché : les deux entrées pointant sur les mêmes octets, modifier les métadonnées de l'original dans DxO changerait aussi silencieusement la copie dans le nouveau projet. |
| | 222 | +- Une vraie copie physique reste cohérente avec le principe déjà posé : chaque projet doit rester lisible et autonome, y compris sans les autres projets présents à côté. |
| | 223 | + |
| | 224 | +**Le checksum reste un lien valable indéfiniment pour retrouver un fichier maître copié — correction du 2026-09-11 par rapport à la première version de cette section.** Cette première version affirmait qu'une "vraie retouche" (recadrage, étalonnage) pour le travail de cohérence du livre change les pixels et donc le checksum, ne laissant que l'identifiant pérenne comme lien fiable. C'était une erreur : le développement RAW est non destructif par nature (section 12) — recadrage, exposition, étalonnage restent des réglages stockés en sidecar (RAW propriétaires, JPEG/TIFF traités en non destructif) ou en métadonnées embarquées (DNG), jamais appliqués aux pixels eux-mêmes. Le fichier maître copié dans le projet livre garde donc son contenu image intact quel que soit le travail de cohérence effectué dessus, tant que ce travail reste non destructif — ce qui est déjà la règle partout ailleurs dans l'archive, pas une exception ici. Concrètement : |
| | 225 | + |
| | 226 | +- RAW propriétaires et JPEG/TIFF traités comme masters : le hash du fichier entier reste stable, retouche comprise. |
| | 227 | +- DNG : le hash du fichier entier bouge à chaque écriture de réglages (comme ailleurs, section 12), mais le hash image-only (`ImageDataHash`) reste stable — c'est donc lui qu'il faut utiliser pour suivre un DNG par checksum sur la durée. |
| | 228 | + |
| | 229 | +Le checksum (image-only pour DNG, fichier entier pour les autres masters) et le nom de fichier archivé (section 10, tant qu'il n'est pas renommé) couvrent donc, à eux deux, la quasi-totalité des besoins de traçabilité vers l'archive d'origine. Confirmé le 2026-09-11 : c'est suffisant pour l'usage courant, pas la peine d'ajouter de mécanisme pour ce cas-là. |
| | 230 | + |
| | 231 | +**Ce qui échappe réellement à checksum + nom, c'est un export/rendu final** (ex. un TIFF prêt à imprimer pour la mise en page du livre) : un nouveau fichier, avec des pixels effectivement différents du maître puisque les réglages y sont "cuits" en dur au moment de l'export, et un nom qui n'a souvent plus de rapport avec le fichier d'origine (renommé pour l'ordre des pages). C'est là, et seulement là, qu'un lien plus robuste que checksum/nom a un intérêt. |
| | 232 | + |
| | 233 | +**Piste à vérifier avant de construire un mécanisme maison pour ce cas résiduel : un standard existant pourrait déjà le couvrir.** Le schéma **XMP Media Management** (`xmpMM`) définit des champs prévus exactement pour ça : `DocumentID` (identifiant commun à toutes les versions/rendus d'une ressource), `OriginalDocumentID` (garde la référence du tout premier fichier source, même après plusieurs conversions de format) et `DerivedFrom` (référence explicite vers le document dont un fichier est dérivé). Lightroom renseigne ces champs automatiquement à l'export d'un dérivé depuis un RAW. Reste à vérifier si DxO PhotoLab fait de même (pas trouvé de confirmation aussi nette pour DxO) — test simple sur un export réel : |
| | 234 | + |
| | 235 | +``` |
| | 236 | +exiftool -DocumentID -OriginalDocumentID -DerivedFrom fichier_exporte.tiff |
| | 237 | +``` |
| | 238 | + |
| | 239 | +Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identifiant pérenne pour ce cas : il suffit de **lire** ce que l'outil d'édition a déjà écrit. L'identifiant pérenne maison (section 3) resterait pertinent seulement si ce test ne donne rien. |
| | 240 | + |
| | 241 | +**Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :** |
| | 242 | + |
| | 243 | +- **Fiche de provenance au moment de la copie** : quand Régine effectue la copie (copie vérifiée par checksum, même logique que l'import carte mémoire section 10 point 1, avec la même vérification de collision de nom), elle enregistre directement dans la base du nouveau projet une petite fiche de provenance (projet source, identifiant du fichier, nom d'origine). Traçabilité immédiate dans le cas courant, sans recherche. |
| | 244 | +- **Recherche inter-projets par identifiant ou checksum, en dernier recours** : pour le cas où la fiche de provenance serait perdue, ou le fichier retrouvé par un autre biais (y compris un export dérivé). Matérialise concrètement le besoin d'index inter-projets déjà anticipé comme "à construire plus tard" en section 13 (recherche en lecture seule dans l'archive) — un outil qui parcourt les bases SQLite de chaque projet (ou un index reconstruit à partir d'elles) pour localiser un identifiant ou un hash donné. |
| | 245 | + |
| 175 | ## Pistes de fonctionnalités pour Régine | 246 | ## Pistes de fonctionnalités pour Régine |
| 176 | | 247 | |
| 177 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. | 248 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. |
| 178 | -- Identifiant pérenne par photo, indépendant du nom de fichier, complémentaire au nom de fichier lisible défini à l'import. | 249 | +- Identifiant pérenne par photo, indépendant du nom de fichier — à construire seulement si la vérification du standard XMP `DerivedFrom`/`OriginalDocumentID` sur les exports DxO s'avère négative, cf. section 14 ; sinon lire ces champs standards suffit pour relier un export dérivé à son maître. |
| 179 | - Notion de fichier maître vs dérivés. | 250 | - Notion de fichier maître vs dérivés. |
| 180 | - Détection de doublons / vérification d'intégrité par checksum. | 251 | - Détection de doublons / vérification d'intégrité par checksum. |
| 181 | - Gestion de niveaux de sélection (brut / sélection / édition finale). | 252 | - Gestion de niveaux de sélection (brut / sélection / édition finale). |
| @@ -183,9 +254,11 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 183 | - 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. | 254 | - 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. |
| 184 | - Profil de boîtiers configurable (déclaré à l'installation, modifiable à tout moment) comme mécanisme principal de désambiguïsation des sources par EXIF `Model`, `BodySerialNumber`/étiquetage manuel gardés en repli pour deux unités identiques du même modèle — cf. section 10, point 6. | 255 | - Profil de boîtiers configurable (déclaré à l'installation, modifiable à tout moment) comme mécanisme principal de désambiguïsation des sources par EXIF `Model`, `BodySerialNumber`/étiquetage manuel gardés en repli pour deux unités identiques du même modèle — cf. section 10, point 6. |
| 185 | - 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. | 256 | - 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. |
| 186 | -- Structure de projet par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, extensible à d'autres formats sans traitement spécifique) avec sélection à la racine (promotion manuelle, par fichier), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF — cf. section 11. | 257 | +- Structure de projet par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, extensible à d'autres formats sans traitement spécifique) avec sélection à la racine (promotion manuelle, par fichier) à deux niveaux pour un projet parent (racine de l'étape, puis racine du voyage comme planche-contact globale), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF — cf. section 11. |
| 187 | - 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. | 258 | - 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. |
| 188 | -- 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. | 259 | +- 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. Ce même hash image-only permet de suivre un DNG par checksum sur la durée, retouche non destructive comprise. |
| | 260 | +- Manifeste persistant en base SQLite unique à la racine du projet principal (parent + sous-projets), avec numéro de format via `PRAGMA user_version`/`application_id` distinguant changement additif (toléré par une version ancienne) vs structurel (refus explicite + migration à prévoir) ; checkout et verrou portent sur le projet complet, jamais un sous-projet isolé — le travail à plusieurs (verrouillage fin par sous-projet) est mis de côté pour le moment — cf. section 13. |
| | 261 | +- Copie vérifiée inter-projets pour composer un nouveau projet (livre, sélection thématique) à partir de l'archive : checksum + nom de fichier suffisent pour retrouver un fichier maître copié (retouche non destructive comprise) ; fiche de provenance enregistrée au moment de la copie et outil de recherche inter-projets en dernier recours, utiles surtout pour le cas résiduel d'un export dérivé — cf. section 14. |
| 189 | | 262 | |
| 190 | ## Sources | 263 | ## Sources |
| 191 | | 264 | |
| @@ -202,3 +275,8 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 202 | - [Digital Negative (DNG) Specification 1.6.0.0 — Adobe](https://paulbourke.net/dataformats/dng/dng_spec_1_6_0_0.pdf) | 275 | - [Digital Negative (DNG) Specification 1.6.0.0 — Adobe](https://paulbourke.net/dataformats/dng/dng_spec_1_6_0_0.pdf) |
| 203 | - [ExifTool ImageDataHash — exiftool-vendored.js (PhotoStructure)](https://github.com/photostructure/exiftool-vendored.js/blob/main/src/ImageDataHashTag.ts) | 276 | - [ExifTool ImageDataHash — exiftool-vendored.js (PhotoStructure)](https://github.com/photostructure/exiftool-vendored.js/blob/main/src/ImageDataHashTag.ts) |
| 204 | - [Image::ExifTool — API options incl. ImageHashType — metacpan.org](https://metacpan.org/dist/Image-ExifTool/view/lib/Image/ExifTool.pod) | 277 | - [Image::ExifTool — API options incl. ImageHashType — metacpan.org](https://metacpan.org/dist/Image-ExifTool/view/lib/Image/ExifTool.pod) |
| | 278 | +- [SQLite — LoC Recommended Storage Format](https://www.sqlite.org/locrsf.html) |
| | 279 | +- [SQLite as an Application File Format](https://sqlite.org/appfileformat.html) |
| | 280 | +- [SQLite PRAGMA statements (user_version, application_id)](https://sqlite.org/pragma.html) |
| | 281 | +- [SQLite — ATTACH DATABASE](https://sqlite.org/lang_attach.html) |
| | 282 | +- [XMP Media Management namespace — Adobe Developer](https://developer.adobe.com/xmp/docs/xmp-namespaces/xmp-mm/) |