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

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

no bmp

Fabien Champigny committed 2026-09-11T16:07:03+02:00 Browse files
d93a297 parent: c3ddef8
modified docs/archivage-photo-elements-cles.md +6 -6
@@ -115,13 +115,13 @@ Séquence retenue :
115115
116116 Structure retenue pour un projet (après plusieurs itérations) :
117117
118-- **Un dossier par format, créé à la demande** selon ce qui est réellement présent dans le projet — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, mais un projet contenant des scans peut aussi avoir `tiff/` et `bmp/` (voire d'autres formats à l'avenir) : Régine crée le dossier de format seulement s'il y a au moins un fichier de ce type à y mettre.
119-- `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/`, `tiff/`, `bmp/`, qui correspondent chacun à une extension précise.
120-- **Racine du projet** : la sélection, prête à être vue directement (y compris en rouvrant le projet dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF/BMP sélectionné.
118+- **Un dossier par format, créé à la demande** selon ce qui est réellement présent dans le projet — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, `tiff/` pour les scans. Un format plus marginal, s'il apparaît, est traité exactement de la même façon (un dossier créé à la demande), sans logique ni migration spécifique pour des formats périmés — pas la peine de complexifier le design pour des cas anecdotiques.
119+- `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/` et `tiff/`, qui correspondent chacun à une extension précise.
120+- **Racine du projet** : la sélection, prête à être vue directement (y compris en rouvrant le projet dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF sélectionné.
121121
122122 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.
123123
124-**Cas des scans TIFF/BMP** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF ou le BMP est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. Point de vigilance propre au BMP : c'est un format ancien, sans embarquement standard de métadonnées et peu utilisé en pratique d'archivage (contrairement au TIFF, largement recommandé pour les scans). Rien d'urgent, mais ça en fait un candidat naturel à une migration future vers TIFF, cohérent avec le principe déjà noté en section 4 ("migrations périodiques planifiées quand un format devient obsolète").
124+**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.
125125
126126 **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.
127127
@@ -145,7 +145,7 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r
145145
146146 **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.
147147
148-**Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF/BMP :**
148+**Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :**
149149
150150 - **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.
151151 - **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.
@@ -180,7 +180,7 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r
180180 - 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.
181181 - 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.
182182 - 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.
183-- 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.
183+- 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.
184184 - 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.
185185 - 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.
186186
@@ -115,13 +115,13 @@ Séquence retenue :
115 115
116 Structure retenue pour un projet (après plusieurs itérations) :116 Structure retenue pour un projet (après plusieurs itérations) :
117 117
118-- **Un dossier par format, créé à la demande** selon ce qui est réellement présent dans le projet — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, mais un projet contenant des scans peut aussi avoir `tiff/` et `bmp/` (voire d'autres formats à l'avenir) : Régine crée le dossier de format seulement s'il y a au moins un fichier de ce type à y mettre.118+- **Un dossier par format, créé à la demande** selon ce qui est réellement présent dans le projet — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, `tiff/` pour les scans. Un format plus marginal, s'il apparaît, est traité exactement de la même façon (un dossier créé à la demande), sans logique ni migration spécifique pour des formats périmés — pas la peine de complexifier le design pour des cas anecdotiques.
119-- `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/`, `tiff/`, `bmp/`, qui correspondent chacun à une extension précise.119+- `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/` et `tiff/`, qui correspondent chacun à une extension précise.
120-- **Racine du projet** : la sélection, prête à être vue directement (y compris en rouvrant le projet dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF/BMP sélectionné.120+- **Racine du projet** : la sélection, prête à être vue directement (y compris en rouvrant le projet dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF sélectionné.
121 121
122 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.122 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 123
124-**Cas des scans TIFF/BMP** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF ou le BMP est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. Point de vigilance propre au BMP : c'est un format ancien, sans embarquement standard de métadonnées et peu utilisé en pratique d'archivage (contrairement au TIFF, largement recommandé pour les scans). Rien d'urgent, mais ça en fait un candidat naturel à une migration future vers TIFF, cohérent avec le principe déjà noté en section 4 ("migrations périodiques planifiées quand un format devient obsolète").124+**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.
125 125
126 **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.126 **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.
127 127
@@ -145,7 +145,7 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r
145 145
146 **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.146 **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.
147 147
148-**Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF/BMP :**148+**Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :**
149 149
150 - **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.150 - **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.
151 - **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.151 - **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.
@@ -180,7 +180,7 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r
180 - 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.180 - 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.
181 - 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.181 - 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.
182 - 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.182 - 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.
183-- 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.183+- 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.
184 - 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.184 - 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.
185 - 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.185 - 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.
186 186