Skip to main content

260827-Tofs a compresse sur le PC Windows

Procédure Photos-Caesium — compression de photos par dépôt de dossier

Mise en place le 2026-08-27 sur le poste Windows julie. Copie de référence de cette page : Jux-scripts/Photos-Caesium/doc_bookstack_284.md.

En bref

On dépose des photos dans un dossier, on les récupère compressées dans un autre. Rien à lancer, rien à paramétrerrégler au coup par coup. C'est le principe de la procédure Komga-PDF (page 220) appliqué aux images.

images,

mais Gain mesuréentièrement sur 71le photosPC de téléphone : 251,1 Mo → 90,4 Mo, soit -64 %, en 22 secondes.julie EXIF,— GPS,le dimensionsVPS etn'intervient dates de prise de vue intégralement conservés.pas.

    Dépôt D:\Procedures photos\Tofs a compresse\ Résultat D:\Procedures photos\Tofs-compressed\ Moteur caesiumclt v1.4.0 (— binaire Rust, local)aucune dépendance Script Jux-scripts/Photos-Caesium/compress_photos.py — stdlib seule Profil actifMachine PC julieq80 uniquement — environ -62 %, sans redimensionnement Délai43 secondes entre le VPSdépôt n'intervientet pasla livraison

PourquoiLa 100seule % local, contrairementchose à Komga-PDF

ne

Komga-PDFjamais passe par le VPS. Photos-Caesium non, et c'est délibéré. Trois raisons, par ordre d'importance :

1. Il n'y a pas de service à réutiliser. Komga-PDF s'appuie sur StirlingPDF, déjà déployé sur le VPS et qui expose compress-pdf en HTTP. Pour les images il n'existe aucun équivalenttoucher : Caesium est un binaire en ligne de commande, pas un service. L'héberger sur le VPS n'apporterait donc pas une API mais un simple exécutable — qu'on peut tout aussi bien poser sur le PC.

2. Le CPU. La compression JPEG (mozjpeg) est du calcul pur, massivement parallélisable. Le Ryzen 5 2600X offre 12 threads et ne fait généralement rien ; le VPS fait tourner une trentaine de containers, avec un swap déjà largement occupé et un antécédent de saturation disque à 100 % (24/06/2026). Les 71 photos de la mesure de référence ont été traitées en 22 secondes sur le PC.

3. Le transfert. Les photos sont déjà sur le PC ou le NAS. Les envoyer au VPS pour les faire revenir consommerait deux fois le débit montant de la Livebox sans contrepartie.

Le seul cas qui justifierait le VPS serait de pouvoir déposer depuis le téléphone pendant que le PC est éteint — c'est exactement ce qui avait fait choisir le VPS pour Komga-PDF. Le portage serait trivial : le dépôtl'option caesium-clt-e publie un binaire linux-musl statique qui tournerait sans rien installer, et le script Python n'utilise que la bibliothèque standard. À reconsidérer si le besoin apparaît.

Pourquoi les dossiers sont hors de l'arbre Syncthing

Les deux dossiers avaient d'abord été créés dans D:\Syncthing\options_communes, puis déplacés versde D:\Procedures photos\config.json. Elle conserve l'EXIF, et ce n'est Il ne faut pas les y remettre.

Il n'existe qu'un seul dossier Syncthing dans tout le maillagecomportement (afltj-njyuy),par partagédéfaut avecde 7Caesium. appareilsSans dontelle, ledates Xiaomide prise de vue et lacoordonnées tabletteGPS SM-T720.sont Toutpurement ce qui tombe dedans se réplique partout. C'est supportable pour Komga-PDFsupprimées — unsilencieusement. PDF de 130 Mo de temps en temps — mais un vidage de carte SD à plusieurs gigaoctets descendrait intégralement sur les téléphones, avant même que la compression ait commencé.

Conséquence assumée : le dépôt à distanceCe n'est pas possible.une Onprécaution déposethéorique depuis: c'est déjà arrivé, le PC.14 juillet 2026, et 275 photos y ont laissé leur GPS définitivement.

Arborescence

D:\Procedures photos\
├── Tofs a compresse\          ← dépôt (sous-dossiers acceptés)
├── Tofs-compressed\           ← résultat, même arborescence
├── originaux-traites\         ← originaux après traitement (créé au besoin)
├── non-traites\               ← formats non pris en charge (créé au besoin)
├── echecs\                    ← abandons après 3 tentatives (créé au besoin)
├── bin\caesiumclt.exe
├── logs\photos_compress.log
├── config.json
├── Compresser maintenant.cmd
├── Simuler le gain.cmd
└── Surveillance (fenetre visible).cmd

Le script lui-même vit dans Jux-scripts/Photos-Caesium/, donc dans l'arbre Syncthing : il est versionné et disponible sur toutes les machines. Seules les données restent locales.

Usage

Au quotidien

DéposerDéposez les photos dans Tofs a compresse\, puis double-cliqueret n'attendez rien d'autre : la tâche CompresserPhotos-Caesium maintenant.cmd.tourne en permanence et les prend d'elle-même. Les fichiers compressés apparaissent dans Tofs-compressed\ avec la même arborescence — un album déposé revient en album.

20:43:51   dépôt dans Tofs a compresse\
20:44:32   déclenchement (après 20 s sans changement)
20:44:34   livraison dans Tofs-compressed\

Le délai tient au garde-fou : la surveillance attend 20 secondes sans le moindre changement avant de traiter, ce qui évite d'attraper un fichier en cours de copie. Si vous videz une carte SD de 300 photos, elle patiente jusqu'à la fin du transfert.

Ce qui devient de vos originaux :

    ils partent dans originaux-traites\ — jamais effacés, c'est le dossier à vider de temps en temps ; un HEIC ou un RAW, que Caesium ne sait pas lire, est écarté dans non-traites\ plutôt que traité ; une photo qui ne gagnerait rien à être compressée est recopiée telle quelle en sortie : un fichier déposé ressort toujours.

    À la main

    Trois lanceurs à double-cliquer dans D:\Procedures photos\ :

    LanceurEffet Compresser maintenant.cmdune passe, puis sortie Simuler le gain.cmd compresse pour de vrai en zone tampon, annonce le gaingain, obtenu, puis jette le résultat sans rien déplacer. Utile pour arbitrer entre deux profils avant de s'engager.

    Surveillance (fenetre visible).cmd laisse tourner la boucle avec laboucle, console à l'écran.écran

    En

    ligne de commande 
    py -3.12 compress_photos.py --une-fois
py -3.12 compress_photos.py --simulation
py -3.12 compress_photos.py --profil sans-perte --une-fois
py -3.12 compress_photos.py --profils
py -3.12 compress_photos.py                     # surveillance continue

    SurveillanceLa surveillance automatique

    à

    Tâche l'ouvertureplanifiée dePhotos-Caesium session(ONLOGON), — en place depuis le 2026-08-27

    Tâche planifiée Photos-Caesium, créée par la commande suivante dans une console PowerShell de Julien :

    schtasks /Create /TN "Photos-Caesium" /TR '"C:\Users\julie\AppData\Local\Programs\Python\Python312\pythonw.exe" "D:\Syncthing\Jux_univers\Jux-scripts\Photos-Caesium\compress_photos.py"' /SC ONLOGON /RL LIMITED /F

    pythonw.exe et non python.exe, sans quoi une console s'ouvre à chaque ouverture de session. Vérification :par schtasks /Query /TN "Photos-Caesium" /V /FO LIST, ou taskschd.msc. Retrait; :retrait par schtasks /Delete /TN "Photos-Caesium" /F.

    pythonw.exe et non python.exe

    , sinon une fenêtre de console s'ouvre à chaque ouverture de session.

    Cette tâche doit être créée pardepuis la console de Julien, pasjamais depuis une session Claude CodeCode. —Une piègesession MSIX,Claude cf.tourne dans un conteneur MSIX : la tâche figerait des chemins virtualisés et ne ferait rien, sans le moindre message. Voir la page 282.282.

    Profils de compression

    Définis dans config.json, modifiables sans toucher au code. --profil <nom> permet de surchargersurcharge ponctuellement.

    Profil Options Caesium Gain sur photos de téléphone q80 (actif par défaut)actif) -q 80 -59 à -72 % q90 -q 90environ ~-45 % sans-perte --lossless -23 % web-3000px -q 80 --long-edge 3000 --no-upscaleenviron ~-85 %

    Options appliquéescommunes à tous les profils (options_communes) : -e --keep-dates --min-savings 1%.

    Le pointprofil importantactif :ne redimensionne pas. q80 ne touche ni aux dimensions ni au nombre d'étiquettes EXIF. web-3000px, qui ramènerait le grand côté à 3 000 pixels, figure dans config.json mais n'est pas sélectionné — à n'activer que sur demande explicite.

    « sansSans altérer la qualité » coûte les deux tiers du gain

    C'était la demande initiale, et elle mérite d'être précisée,précisée parce que: les deux modes de Caesium n'ont rien de comparable en rendement :rendement.

    • --lossless ne touche pas un seul pixel. Il reconstruit les tables de Huffman et réoptimise le conteneur. Sur les mêmes 71 photos réelles : -23 %.
    • -q 80 ré-encode l'image. La différence est invisible à l'œil sur une photographie, et c'est le réglage par défaut de l'interface graphique Caesium — celui qui donne l'impression que « Caesium compresse admirablement bien ». Sur les mêmes fichiers : -64 %.

    D'où le choix de q80 par défaut. Pour des originaux irremplaçables, basculer sur sans-perte dans config.json, ou traiter ce lot-là avec --profil sans-perte.

    Mesure de référence — 2026-08-27

    71 photos de téléphone (lot « Ligurie 2026 »), Ryzen 5 2600X, --threads 0 (12 threads) :

      Taille Durée Originaux 251,1 Mo — q80 90,4 Mo (-64,0 %) 22 s sans-perte (sur un sous-ensemble) -22,8 % —

    Soit environ 12 Mo/s de débit de traitement. Un vidage de carte SD de 8 Go se traite donc en une dizaine de minutes.

    Ce qui est garanti : EXIF, GPSGPS, dates, dimensions

    Vérifié deux fois, par la mesure et dates — vérifiés

    -e (garder l'EXIF) n'est PAS le comportementnon par défaut de Caesium. Sans cette option, dates de prise de vue et coordonnées GPS sont purement supprimées — ce qui serait fâcheux avant tout versement dans Immich. L'option est donc dans options_communes : ne pas la retirer.

    Contrôle effectué le 2026-08-27 sur trois photos, en comparant original et compressé :

    Fichier Taille Dimensions Bloc EXIF GPS DateTimeOriginal IMG_20260805_110420 orig. 3 303 207 o 1970×2997 1 819 o oui 2026:08:05 10:31:44 IMG_20260805_110420 q80 669 121 o 1970×2997 1 819 o oui identique IMG_20260814_103531 orig. 2 647 488 o 4096×3072 52 665 o oui 2026:08:14 10:35:31 IMG_20260814_103531 q80 952 436 o 4096×3072 52 665 o oui identique IMG_20260815_161301 orig. 2 145 571 o 3072×4096 52 597 o oui 2026:08:15 16:13:01 IMG_20260815_161301 q80 649 956 o 3072×4096 52 597 o oui identique

    Bloc EXIF identique à l'octet près, IFD GPS présent, dimensions inchangées, --keep-dates préservant par ailleurs les horodatagesrelecture du fichier lui-même.code.

    Formats

    Pris en charge : JPEG, PNG, WebP, GIF, TIFF.

    Non pris en charge : HEIC (iPhone) et RAW. Ces fichiers sont déplacés dans non-traites\ — jamais supprimés — avec une ligne au journal. Caesium ne sait pas les lire ; si le besoin HEIC se présente, il faudra une étape de conversion en amont.

    Fonctionnement interne

      Sondage toutes les 15 s du dossier de dépôt. Il n'y a pas d'inotify sous Windows : le sondage est la seule voie, et c'est de toute façon la partie robuste du dispositif (voir le correctif Komga-PDF du 23/08). Traitement déclenché après 20 s sans le moindre changement dans l'arborescence — taille ou date d'un fichier quelconque. C'est ce qui évite d'attraper un fichier en cours de copie. Plafond de sécurité à 15 min, au-delà duquel on traite quand même. Le lot entier part en un seul appel à caesiumclt, qui parallélise sur tous les cœurs (--threads 0). Écriture d'abord dans .staging, puis déplacement vers la sortie. Jamais de fichier partiel visible dans Tofs-compressed\. Structure préservée (-R -S). Collision de nom en sortie : suffixe  (2),  (3)… Rien n'est jamais écrasé. Gain inférieur à 1 % (--min-savings 1%) : Caesium n'écrit rien, et le script recopie l'original tel quel en sortie. Un fichier déposé ressort toujours. Échec : 3 tentatives (clé taille + date de modification, mémorisée dans .etat.json), puis mise à l'écart dans echecs\. Journal persistant logs\photos_compress.log, rotation à 5 Mo. Sort des originaux — config.json, clé apres_traitement : deplacer (défaut, vers originaux-traites\), supprimer, ou laisser.

      Les points 2, 4, 7, 8 et 9 reprennent d'emblée les correctifs apportés à komga_watch_vps.sh le 2026-08-23 (page 220) : événements perdus pendant le traitement, écriture non atomique, absence de mémoire des échecs, journal volatil. Autant ne pas refaire les mêmes erreurs.

      ⚠ apres_traitement: "laisser" fait retraiter le dépôt en boucle à chaque passe. À réserver aux tests.

      Pièges rencontrés à l'installation

      1. --dry-run de Caesium ne mesure rien. L'option existe et s'exécute sans erreur, mais le rapport JSON renvoie compressed_size == original_size, soit un gain annoncé de 0,0 %. Elle simule l'écriture, pas la compression. Le mode --simulation du script ne l'utilise donc pas : il compresse réellement dans .staging, relève le chiffre, puis jette le résultat. C'est plus coûteux en CPU, mais c'est le seul moyen d'obtenir une estimation honnête.

      2. -e n'est pas le défaut. Voir plus haut — perte silencieuse des dates et du GPS.

      3. --json est la bonne interface de pilotage. Caesium renvoie un rapport structuré, une entrée par fichier (original_path, output_path, original_size, compressed_size, status, message) plus un summary. Tout le script s'appuie dessus plutôt que de parser la sortie texte.

      4. --min-savings rend inutile le garde-fou maison. Sur Komga-PDF il avait fallu écrire à la main la règle « si la compression ne gagne rien, recopier l'original ». Caesium l'implémente nativement : sous le seuil, il n'écrit pas de fichier de sortie. Le script se contente de détecter l'absence et de recopier.

      5. Création de la tâche planifiée depuis Claude Code : à éviter. Une session Claude Code tourne dans un conteneur MSIX (page 282). La création a par ailleurs été refusée par le garde-fou de la session — ce qui tombe bien. C'est à Julien de la créer depuis sa propre console.

      6. Le binaire ne s'installe pas. caesiumclt.exe est un exécutable Rust statique de 5,7 Mo, sans dépendance ni installeur. Il se dépose dans bin\ et se met à jour en le remplaçant.

      Le binaire

        Version : caesiumclt v1.4.0, publiée le 8 juillet 2026 Source : https://github.com/Lymphatus/caesium-clt/releases Archive : caesiumclt-v1.4.0-x86_64-pc-windows-msvc.zip — 2 296 760 octets SHA-256 : a56454a83207fc25830f4d12679d7385c0906060f2ce5f54345ac5a4cf94b00f Licence : GPL / MPL selon les composants (bin\LICENSE.md)

        Le même dépôt publie caesiumclt-v1.4.0-x86_64-unknown-linux-musl.tar.gz, statique, qui permettrait de porter la procédure sur le VPS ou Ubuntu sans modifier une ligne du script.

        Maintenance

          Vider originaux-traites\ de temps en temps : les originaux y sont conservés, pas effacés. C'est le dossier qui grossit. Surveiller non-traites\ : s'il se remplit, c'est que des HEIC ou des RAW arrivent dans le flux. echecs\ doit rester vide. Toute entrée signale un fichier corrompu ou un cas non prévu — consulter le journal. Journal : D:\Procedures photos\logs\photos_compress.log, rotation automatique à 5 Mo.

          Reste à faire

            Décider du sort du lot de démonstration laissé dans Tofs-compressed\Ligurie 2026\ (71 photos, 90 Mo) — il sert à juger la qualité q80 à l'œil, les originaux correspondants étant restés dans D:\Syncthing\PDF temps\photos Ligurie a traiter\

            Voir aussi

              Page 220 — Procédure Komga-PDF, dont celle-ci reprend le principe et les correctifs Page 282 — piège MSIX de Claude Code sur le poste julie Page 211 — retour d'expérience StirlingPDF (la voie serveur, écartée ici)

              ⚠ Le -e manquant a deja fait des degats — passe du 2026-07-14

              Cette page insiste sur le fait que -e n'est pas le defaut de Caesium et que sans lui l'EXIF disparait. Ce n'est pas une precaution theorique : une passe anterieure a la mise en place de la procedure, le 2026-07-14, a ete lancee sans cette option.

              Degats constates le 2026-08-28, sur les photos de l'ete 2026 : 275 fichiers depouilles de tout bloc EXIF — date et GPS. Signature : 493 Ko de moyenne pour les fichiers traites, contre 1103 Ko pour les 76 intacts du meme voyage.

              Consequence differee, invisible sur le moment : sans DateTimeOriginal, Immich se rabat sur la date du fichier. Or le WebDAV kDrive ne preserve pas les mtime — a la premiere resynchronisation, six semaines plus tard, les 275 photos sont allees se ranger au jour de la synchro et la chronologie du voyage s'est effondree.

              Le GPS, lui, est definitivement perdu. Seule la date a pu etre reconstruite, a partir du nom des fichiers, par Jux-scripts/Photos-Caesium/dater_photos_nas.py. Recit complet et methode : page 164 (13_Immich).

              A retenir avant toute passe de compression : verifier -e dans la ligne de commande et controler l'EXIF d'un fichier de sortie avant de traiter un lot. Un fichier de sortie sans bloc EXIF doit faire arreter la passe immediatement — les originaux ne sont pas toujours recuperables.

              Contrôle du 2026-09-28 — la chaîne réelle, mesurée de bout en bout

              Question de Julien : « la procédure Photos-Caesium du PC est bien la même que celle appliquée sur le NAS ? Notamment elle embarque le maintien des EXIF des photos sans les aplatir ? » — vérifié par la mesure, sur la chaîne réelle, et non par relecture du code.

              Oui. Bloc EXIF identique à l'octet près, GPS au chiffre près, 72 étiquettes sur 72 conservées, dimensions et date de fichier inchangées. Rien n'est aplati ni simplifié : Caesium ne réécrit que les données d'image.

              Protocole

              Trois photos du Xiaomi 15T ProPro, (dont deux géolocalisées) mises de côté en référence, puisgéolocalisées, déposées dans Tofs a compresse\ sans rien lancer —: c'est la tâche Photos-Caesium en surveillance qui les a prises, comme pour un dépôt ordinaire. Comparaison ensuite entre la référence et la sortie.

              ContrôleRésultat
              Bloc EXIFidentique à l'octet près — 52 334 / 52 740 / 52 782 octets, inchangésoctets
              Coordonnées GPS43.675676, 4.634059 avant et aprèsaprès, (Camargue)au chiffre près
              Date de prise de vueidentique à la seconde
              Nombre d'étiquettesÉtiquettes EXIF72 → 72 (58 → 58 pour la photo sans GPS)
              Dimensions4096×3072 inchangées — aucun redimensionnement
              Date de fichier (mtime)identique — --keep-dates tient
              Poids13,1 Mo → 5,1 Mo, -61 %

              Les 72 étiquettes conservées couvrent tout ce que l'appareil écrit : marque, modèle, objectif, ouverture, temps de pose, ISO, orientation, balance des blancs, et le bloc GPS complet. Rien n'est aplati ni simplifié — Caesium ne réécrit que les données d'image.

              Chronologie mesurée : dépôt à 20:43:51, déclenchement à 20:44:32 (les 20 secondes

              Mesure de calme)référence du 2026-08-27

              71 photos de téléphone (lot « Ligurie 2026 »), livraisonRyzen à5 20:44:342600X, --threads 0 :

              TailleDurée Originaux251,1 Mo— q8090,4 Mo (-64,0 %)22 s sans-perte-22,8 %—

              Soit environ 4312 secondesMo/s de boutdébit : un vidage de carte SD de 8 Go se traite en bout,une sansdizaine intervention.

              de

              Originauxminutes. vérifiésLe intactscontrôle :EXIF lesde ce jour-là portait sur trois fichiers sourceset dedonnait l'arbredéjà Syncthingun sontbloc identiquesEXIF identique à l'octet (1 819 / 52 665 / 52 597 octets), IFD GPS présent, dimensions inchangées.

              L'outil de contrôle

              Jux-scripts/Photos-Caesium/comparer_exif.py — stdlib seule. Prend deux dossiers et compare fichier par fichier : bloc EXIF octet par octet, GPS converti en degrés décimaux, DateTimeOriginal, appareil, dimensions, nombre d'étiquettes, mtime, poids.

              py -3.12 comparer_exif.py <dossier_reference> <dossier_sortie>

              Il rend un verdict global, et se prête au contrôle de sanité : lancé avec le même dossier des deux côtés, il doit tout déclarer conforme. À rejouer après l'opérationtoute modification de profil, de config.json ou du binaire.

              ⚠ L'incident du 2026-07-14 — le test-e n'manquant

              Une passe antérieure à la mise en place de cette procédure a portéété quelancée sans -e.

              Dégâts constatés le 2026-08-28, sur les photos de l'été 2026 : 275 fichiers dépouillés de tout bloc EXIF — date et GPS. Signature nette : 493 Ko de moyenne pour les fichiers traités, contre 1 103 Ko pour les 76 intacts du même voyage.

              Conséquence différée, invisible sur le moment. Sans DateTimeOriginal, Immich se rabat sur la date du fichier. Or le WebDAV kDrive ne préserve pas les mtime : à la première resynchronisation, six semaines plus tard, les 275 photos sont allées se ranger au jour de la synchro et la chronologie du voyage s'est effondrée.

              Le GPS est définitivement perdu. Seule la date a pu être reconstruite, depuis le nom des copies.fichiers, par dater_photos_nas.py. Récit complet : page 164.

              À faire avant toute passe de compression : vérifier -e dans la ligne de commande, et contrôler l'EXIF d'un fichier de sortie avant de traiter le lot. Un fichier de sortie sans bloc EXIF doit faire arrêter la passe immédiatement — les originaux ne sont pas toujours récupérables.

              PC et NAS : le même moteur, une garantie de plus sur le NAS

              Le stock photo du NAS suit sa propre procédure, en quatre étapes avec validation humaine (page 285). Le moteur, lui, est rigoureusement le même.

              PC (compress_photos.py)NAS (traiter_lot_nas.py)
              Binairecaesiumclt 1.4.0, identique
              Profil-q 80, identique
              Options communes-e --keep-dates --min-savings 1%, identiques
              Date /et propriétaire réimposés puis revérifiésnonoui (calquer() : os.utime, os.chown, os.chmod, puis relecture)

              La différence ne porte pas sur l'EXIF, qui estEXIF, protégé à l'identique par -e dans lesdes deux cas.côtés. Elle porte sur la date de fichier et le propriétaire, et elle existe pour une raison propre au NAS : les photos y appartiennent à admin:users, et une compression lancée sans privilèges les réattribuerait toutes en cassant SMB et Synology Photos. Sur le PC il n'y a qu'un utilisateur, et la mesure ci-dessus montre que --keep-dates suffitsuffit.

              Formats

              Pris en charge : JPEG, PNG, WebP, GIF, TIFF.

              Non pris en charge : HEIC (iPhone) et RAW. Ces fichiers partent dans non-traites\ — jamais supprimés — avec une ligne au journal. Si le besoin HEIC se présente, il faudra une étape de conversion en amont : Caesium ne sait pas le lire.

              Arborescence

              D:\Procedures photos\
├── Tofs a compresse\          ← dépôt (sous-dossiers acceptés)
├── Tofs-compressed\           ← résultat, même arborescence
├── originaux-traites\         ← originaux après traitement
├── non-traites\               ← formats non pris en charge
├── echecs\                    ← abandons après 3 tentatives
├── bin\caesiumclt.exe
├── logs\photos_compress.log
├── config.json
├── Compresser maintenant.cmd
├── Simuler le gain.cmd
└── Surveillance (fenetre visible).cmd

              Le script, lui, vit dans Jux-scripts/Photos-Caesium/, donc dans l'arbre Syncthing : versionné et disponible sur toutes les machines. Seules les données restent locales.

              Pourquoi les dossiers sont hors de Syncthing

              Ils avaient d'abord été créés dans D:\Syncthing\, puis déplacés. Ne pas les y remettre.

              Il n'existe qu'un seul dossier Syncthing dans tout le maillage (afltj-njyuy), partagé avec 7 appareils dont le Xiaomi et la tablette SM-T720. Tout ce qui y tombe se réplique partout. C'est supportable pour Komga-PDF — un PDF de 130 Mo de temps en temps — mais un vidage de carte SD descendrait intégralement sur les téléphones, avant même que la compression ait commencé.

              Conséquence assumée : le dépôt à distance n'est pas possible, on dépose depuis le PC.

              Maintenance

                Vider originaux-traites\ de temps en temps — les troisoriginaux mtimey sont identiquesconservés, àpas laeffacés. seconde. Ajouter la même vérification au script du PC représenterait une quinzaine de lignes ; la mesure neC'est le réclamedossier pas.qui grossit.

                Le

                Surveiller profilnon-traites\ actif— nes'il redimensionnese pasremplit,

                Ledes profilHEIC enou servicedes estRAW arrivent dans le flux.

                q80echecs\ doit rester vide. Toute entrée signale un fichier corrompu ou un cas non prévu : consulter le journal. Journal : illogs\photos_compress.log, nerotation toucheautomatique nià aux5 dimensionsMo. ni au

                Reste nombreà d'étiquettes.faire Le: profildécider web-3000pxdu présentsort du lot de démonstration laissé dans config.jsonTofs-compressed\Ligurie 2026\ ramènerait(71 photos, 90 Mo), qui sert à juger la qualité q80 à l'œil.

                Annexe — fonctionnement interne

                  Sondage toutes les 15 s du dossier de dépôt. Il n'y a pas d'inotify sous Windows ; le grandsondage côtéest àde 3toute 000façon pixelsla partie robuste du dispositif. Déclenchement après 20 s sans le moindre changement dans l'arborescence — il est disponible mais non sélectionné, et ne le sera que sur demande explicite.

                  L'outil de contrôle

                  Jux-scripts/Photos-Caesium/comparer_exif.py — stdlib seule, aucune dépendance. Prend deux dossiers (référence et sortie) et compare fichier par fichier : bloc EXIF octet par octet, GPS converti en degrés décimaux, DateTimeOriginal, appareil, dimensions, nombre d'étiquettes, mtime, poids.

                  py -3.12 comparer_exif.py <dossier_reference> <dossier_sortie>

                  Il rend un verdict global et se prête au contrôle de sanité : lancé avec le même dossier des deux côtés, il doit tout déclarer conforme. À rejouer après toute modification du profil, de config.jsontaille ou du binaire — et en particulier pour honorer la règle de la section précédente : contrôler l'EXIFdate d'un fichier quelconque. Plafond de sécurité à 15 min, au-delà duquel on traite quand même.

                  Le lot entier part en un seul appel à caesiumclt, qui parallélise sur tous les cœurs (--threads 0). Écriture d'abord dans .staging, puis déplacement : jamais de fichier partiel visible dans Tofs-compressed\. Structure préservée (-R -S). Collision de nom en sortie avant: suffixe  (2),  (3)… Rien n'est jamais écrasé. Gain inférieur à 1 % (--min-savings 1%) : Caesium n'écrit rien, le script recopie l'original tel quel. Mémoire des échecs : 3 tentatives (clé taille + date, dans .etat.json), puis mise à l'écart dans echecs\. Journal persistant avec rotation à 5 Mo.

                  Les points 2, 4, 7, 8 et 9 reprennent d'emblée les correctifs apportés à komga_watch_vps.sh le 2026-08-23 (page 220) : événements perdus pendant le traitement, écriture non atomique, absence de traitermémoire des échecs, journal volatil. Autant ne pas refaire les mêmes erreurs.

                  config.json, clé apres_traitement : deplacer (défaut), supprimer, ou laisser. laisser fait retraiter le dépôt en boucle à chaque passe — à réserver aux tests.

                  Annexe — pièges rencontrés à l'installation

                    --dry-run de Caesium ne mesure rien. L'option existe et s'exécute sans erreur, mais le rapport JSON renvoie compressed_size == original_size, soit 0,0 % de gain : elle simule l'écriture, pas la compression. Le mode --simulation du script compresse donc réellement dans .staging, relève le chiffre, puis jette le résultat. -e n'est pas le défaut — perte silencieuse des dates et du GPS. Voir l'incident ci-dessus. --json est la bonne interface de pilotage. Caesium renvoie un lotrapport structuré, une entrée par fichier (original_path, compressed_size, status…) plus un summary. Le script s'appuie dessus plutôt que de parser la sortie texte. --min-savings rend inutile le garde-fou maison. Sur Komga-PDF il avait fallu écrire à la main la règle « si la compression ne gagne rien, recopier l'original » ; Caesium l'implémente nativement. Créer la tâche planifiée depuis Claude Code : à éviter (piège MSIX). La création avait d'ailleurs été refusée par le garde-fou de session — ce qui tombait bien. Le binaire ne s'installe pas. caesiumclt.exe est un exécutable Rust statique de 5,7 Mo, sans dépendance ni installeur : on le dépose dans bin\ et on le met à jour en le remplaçant.

                    Annexe — le binaire

                    Versioncaesiumclt v1.4.0, publiée le 8 juillet 2026 Sourcegithub.com/Lymphatus/caesium-clt/releases Archivecaesiumclt-v1.4.0-x86_64-pc-windows-msvc.zip — 2 296 760 octets SHA-256a56454a83207fc25830f4d12679d7385c0906060f2ce5f54345ac5a4cf94b00f LicenceGPL / MPL selon les composants (bin\LICENSE.md)

                    Le même dépôt publie caesiumclt-v1.4.0-x86_64-unknown-linux-musl.tar.gz, statique — c'est lui qui tourne sur le NAS, sans Docker ni Entware.

                    Annexe — pourquoi 100 % local, contrairement à Komga-PDF

                    Komga-PDF passe par le VPS. Photos-Caesium non, et c'est délibéré. Trois raisons, par ordre d'importance :

                      Il n'y a pas de service à réutiliser. Komga-PDF s'appuie sur StirlingPDF, déjà déployé et qui expose compress-pdf en HTTP. Pour les images, aucun équivalent : Caesium est un binaire en ligne de commande, pas un service. L'héberger sur le VPS n'apporterait pas une API, juste un exécutable — qu'on peut aussi bien poser sur le PC. Le CPU. La compression JPEG est du calcul pur, massivement parallélisable. Le Ryzen 5 2600X offre 12 threads et ne fait généralement rien ; le VPS fait tourner une trentaine de conteneurs, avec un swap déjà occupé et un antécédent de saturation disque à 100 %. Le transfert. Les photos sont déjà sur place. Les envoyer au VPS pour les faire revenir consommerait deux fois le débit montant de la Livebox sans contrepartie.

                      Le seul cas qui justifierait le VPS serait de pouvoir déposer depuis le téléphone pendant que le PC est éteint — c'est précisément ce qui avait fait choisir le VPS pour Komga-PDF. Le portage serait trivial (binaire linux-musl statique, script en stdlib seule). À reconsidérer si le besoin apparaît.

                      Voir aussi

                        Page 285 — les photos du NAS : procédure en quatre étapes avec validation humaine Page 220 — Komga-PDF, dont celle-ci reprend le principe et les correctifs Page 164 — Immich : réparation des dates après l'incident du -e manquant Page 282 — le piège MSIX de Claude Code sur le poste julie

                        Copie de référence de cette page : Jux-scripts/Photos-Caesium/doc_bookstack_284.md. Mise en place le 2026-08-27, page réécrite intégralement le 2026-09-28..

                        Back to top