Idée: floutage différentiel

Plusieurs problèmes se posent à nous en matière de floutage non pas sur le floutage lui même mais sur le stockage des images, floutée ou pas, etc.

Les algorithmes de floutages ne sont pas parfaits il y a des risques de faux positifs (trop de floutage) ou de faux négatifs (zones non floutées qui devraient l’être).

  • Ne conserver que la version floutée empêche de “déflouter” les faux positifs.
  • Conserver la version originale non floutée pose des problèmes de sécurité et/ou de respect CNIL/RGPD

Le code actuel de geovisio/panoramax, calcule et stocke un masque de floutage (un petit PNG noir et blanc), puis l’applique sur les images avant leur visualisation, ce qui pose d’autres problèmes:

  • stockage des images brutes non floutées (et donc risques en terme RGPD + sécurité associée)
  • calcul de floutage à faire avant visualisation (et/ou gestion d’un cache… donc stockage supplémentaire)

Pour résoudre ces différents problèmes, il serait possible de:

  • calculer le masque de floutage comme actuellement
  • extraire les zones à flouter en éliminant tout le reste de l’image (décontextualiser les parties à flouter), et les stocker à part en éliminant tout contexte (position, temps)
  • générer une version floutée de l’image
  • supprimer l’image originale

De cette façon, plus besoin de cache, plus besoin de calcul de floutage à la visualisation, plus d’original conservé, possibilité de reprendre des zones floutées en faux positif pour les réintégrer dans l’image visualisable.

Les extraits seuls contiendraient des visages ou des plaques d’immatriculation mais sans aucun autre contexte ce qui ne permet pas d’obtenir ou déduire plus d’infos.

On peut conserver ces extraits non floutés et les référencer à l’aide d’un hash, qui ne permettrai pas de remonter à l’image d’origine, ce qui apporterai une sécurité de plus si un accès à ces extraits n’était pas aussi bon qu’imaginé.

Qu’en pensez-vous ?

1 « J'aime »

Je comprends l’idée générale mais pas ce point : quel que soit le mécanisme (hash ou autre) il faut bien à un moment un lien entre l’image d’origine et le masque, pour ne pas appliquer n’importe quel masque à n’importe quelle image, non ?

Bonne idée mais es que le total de image floutée plus image de la partie floutée est égale a la taille de l’image non floutée ?
On risque juste de se retrouver avec bien plus d’images.

Et comme évoqué le stockage des deux partie est séparé pour éviter les problèmes de sécurité et de faciliter de reassocier les deux image en cas de compromission de la sécurité ?

Je trouve l’idée plutôt bonne.

J’espère que la Cnil sera du même avis.

Il y a juste une situation qui demandera plus de ressource au serveur : Lorsque l’auteur d’une photo voudra récupérer la photo originale non floutée, en supposant que Panoramax autorise cette possibilité. Je crois qu’on n’a pas trop discuté de ça.

Oui, il y a un lien, mais dans une seule direction: image floutée → parties non floutées.

Le but est que si on n’a que les visage ou plaques, on ne peut pas retrouver (facilement) le contexte, c’est à dire le reste de l’image et ses métadonnées (géoréférencement + datation).

On peut aussi envisager de détruire les parties non floutées au bout d’un certain délais.

Pour un cliché on a 2 images stockées:

  • la complète avec floutage (volume assez proche de l’original)
  • celle avec juste les zones non floutées, le reste étant mis à blanc, donc bien allégée en volume

Je n’ai pas encore fait de tests pour avoir une idée du résultat, des volumes, etc…

Ce sera en principe possible mais sûrement un traitement rare.

Je me posais la question sur la capacité à traiter du JPEG en ne touchant qu’aux blocs de 8x8 pixels, pour limiter les dégradations dues aux compressions/décompressions. J’ai un peu cherché mais rien trouvé utilisant cette technique (peut être impossible).

Petit essai avec imagemagick pour voir ce que ça donne en volume:

L’image d’origine fait 3.3Mo, voici l’image floutée, elle fait 3.1Mo.

Voici les détails isolés, qui pèsent 314Ko :

On a donc quasiment le même volume de stockage que l’image d’origine, voire un peu moins en passant en JPEG progressif (2.8Mo et 276Ko, soit à peine plus de 3Mo).

Je n’ai fait le test que sur une image, à confirmer sur des séquences variées…

1 « J'aime »

Voilà, j’ai trouvé… jpegtran !

https://manpages.debian.org/testing/libjpeg-turbo-progs/jpegtran.1.en.html

jpegtran permet de manipuler des fichiers JPEG sans décompression/recompression donc en minimisant les pertes (voire sans perte).

Avec les versions 2.1.x on a 3 fonctions qui permettent:

  • de faire un recadrage (crop) pour ne garder qu’une portion de l’image
  • de faire un remplacement (drop) d’une zone de l’image par une autre image
  • de supprimer (wipe) des zones d’une image et les mettant en gris ou un aplat issu des blocs voisins

Tout cela se fait sur les blocs de base de 8x8 pixels sans les modifier et donc sans perte ni calcul complexes (ça doit normalement être rapide).

Un truc de plus à tester !

1 « J'aime »

Bonjour

L’idée de Christian est très intéressante. Stocker les parties “sensibles” hors de leur contexte est une très bonne idée.
Pour la réalisation technique, la question est de garantir que le lien “parties floutées” vers “images floutées” soit impossible à retrouver.

Concernant jpegtran, c’est un “vieil” outil de la LibJpeg (qui a été repris par la lib Jpeg-turbo). Il existe même un utilitaire sous Windows pour éviter de passer par la ligne de commande : https://jpegclub.org/jpegcrop.zip. Donc c’est un outil qui marche bien.

Cordialement

1 « J'aime »

Moment nostalgie !

En ouvrant le code C de jpegtran je suis tombé sur…

Capture d’écran du 2023-02-20 09-24-48

C’est le tout premier morceau de code que j’ai programmé, sur la HP41C de mon prof de physique alors que j’étais en 4ème !

Ça me paraît bien dans l’ensemble.
Pour ce qui est de la conservation sur une durée limitée, je ne suis pas un spécialiste mais il me semble que c’est obligatoire en France : Question | CNIL (je sais bien qu’il ne s’agit pas de vidéoprotection mais bon ça pourrait y ressembler) et Question | CNIL.
Un avis de la CNIL serait sans doute bienvenu.

Chouette idée si cela permet de limiter les risques côté RGPD en sortant les morceaux d’images “sensibles” de leur contexte. Par contre le floutage avec des grosses emprises en noires à éviter vraiment. On perd en lisibilité je trouve. Il vaut mieux un floutage comme sur la photo de Christian du 14 février.

La mise au noir, c’est plutôt du “caviardage” (gris bien foncé le caviar, normalement).

Donc oui, on fera plutôt du flou pour le floutage… qui peut même se faire en modifiant juste les blocs 8x8 JPEG en réduisant leurs données.

Je n’avais jamais creusé en détail le fonctionnement de JPEG.
J’ai découvert qu’on peut faire des JPEG avec des zones de résolution différente (ça serait pas mal pour le floutage) mais bien que ce soit dans le standard, ce n’est pas systématiquement supporté par les décodeurs car vraiment trop peu utilisé.

Et voici un premier test de floutage par manipulation des blocs JPEG de 8x8 pixels…

Je viens d’ajouter une implémentation de ce floutage différentiel dans l’API de floutage sur laquelle je travaille.

L’objectif est de conserver les zones floutées pouvant être des faux positifs pour pouvoir les remettre dans l’image diffusée.

Pour réduire les possibilités d’exploitation:

  • les parties originale d’images à flouter sont conservée chacune dans un fichier JPEG séparé
  • seuls les objets avec un faible taux de confiance sont conservés (plus probablement des faux positifs)
  • le fichier n’a aucune métadonnée,
  • sa date de création/modification est fixée au jour de traitement mais à minuit,
  • cette date permet d’éliminer automatiquement ces fichiers au bout d’un temps à définir
  • le nom du fichier est un hash basé sur le résultat de la détection d’objets pour l’image entière et pour l’objet en question,
  • ce nom ne permet pas de savoir que deux objets appartiennent à la même image d’origine

Les infos sur les objets floutés dans une image sont conservées dans un JSON comme commentaire JPEG dans sa version floutée.

Exemple:
[{'class': 'plate', 'confidence': 0.784, 'xywh': [2528, 1808, 224, 96]}, {'class': 'plate', 'confidence': 0.216, 'xywh': [1840, 1760, 96, 48]}]

Ceci permet de savoir quelles portions ont été floutée et pourquoi (classe et confiance).

Pour “déflouter” il faut donc :

  • les données de floutages contenues dans l’image floutée
  • calculer les hash pour retrouver les parties originales
  • réintégrer ces parties dans l’image JPEG floutée par manipulation de blocs JPEG (un “drop” avec jpegtran).

Première implémentation du défloutage et ça fonctionne très bien !