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é.
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é ?
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).
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…
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.
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é.
