Pour mieux se rendre compte du résultat du floutage, voici quelques séries de photos floutées :
Il y a quelques faux négatifs… combien en trouvez-vous ?
Pour mieux se rendre compte du résultat du floutage, voici quelques séries de photos floutées :
Il y a quelques faux négatifs… combien en trouvez-vous ?
Suite aux retours du côté OpenStreetMap, j’ai réduit encore la pixelisation des zones floutées, pour passer d’un maximum de 16 pixels de côté à 12 pixels.
En effet, les algorithme de reconnaissance faciale semblent actuellement capable de reconnaître un visage à partir d’une image de 24x24 pixels. En descendant le floutage à 12x12 maximum, on garde une marge de sécurité car cela fait 4 fois moins de pixels en tout et 4 fois moins d’informations.
La repasse à 12 pixels est visible ici: Nextcloud
S’il existe un risque de reconnaître des personnes même avec une image floutée (d’ailleurs, risque accentué par la possibilité de croiser l’image floutée avec d’autres informations présentes dans l’image) je propose de ne pas flouter mais de carrément appliquer un aplat de couleur opaque sur la zone. C’est sans doute moins joli mais on afficherait clairement la volonté de protéger au maximum l’intérêt des personnes en question.
Effectivement l’équilibre est pas simple. Est-ce que Christian tu as trouvé une réponse sur “le nombre de pixels à partir duquel on peut distinguer un visage ?”. Je trouve que le masque complet dégrade tout de même la lisibilité de l’image, même si c’est effectivement une approche intéressante.
La plus petite taille que j’ai repéré dans mes recherches c’est 24x24 pixels.
Quand je regarde ce que Google fait, je pense que mes 12 pixels sont plus “flou”:
L’aplat gris est une option, je peux même rendre le mode de floutage paramétrable lors de l’appel à l’API.
J’espère pouvoir montrer cela de façon informelle à quelques contacts à la CNIL et savoir aussi si ils ont une recommandation claire à ce sujet.
J’envisage de faire un test avec l’API de reconnaissance de célébrités que propose Amazon et de voir à partir de quand la détection ne fonctionne plus.
Quand je regarde les résultats de floutage, je trouve que ce n’est pas assez fort, surtout quand les visages commencent à être grands dans la photo. Tu appliques bien le nivellement sur les 3 composantes Y, Cb et Cr? (Au passage, Cb et Cr sont généralement sous-échantillonnés et les patchs élémentaires couvrent 16x8 pixels²). Ma suggestion serait de mettre tous les patchs contigus au même niveau moyen, plus qu’un gris uniforme pas très esthétique.
Et même 16x16 pour le 4:2:0 !
J’ai commencé par une pixellisation uniquement au niveau des blocs JPEG en faisant un décodage partiel de ceux-ci (ce que tu appelles nivellement si je ne me trompe pas), mais ça ne suffisait vraiment pas sur les zones un peu étendues (proches) et c’était assez moche (ce que j’essaye aussi d’éviter).
Donc le floutage en lui même n’est plus fait au niveau JPEG, mais avec pillow (donc en RGB):
Ensuite seulement ce petit bout de JPEG vient remplacer les blocs originaux qui peuvent être en 8x8, 8x16, 16x8 ou 16x16.
Le code est ici: sgblur/blur.py at master · cquest/sgblur · GitHub
Je pense que c’est le boxblur qui donne cette impression que ce n’est pas si flou, ainsi que le bruit ajouté par la basse qualité JPEG, mais il n’y a pas plus d’info qu’une image de 12 pixels de côté.
Il serait même envisageable de générer un faux visage ou de modifier une plaque d’immatriculation par IA
J’ai sûrement extrait assez de visages et de plaques pour entraîner un modèle génératif… le problème c’est qu’on ne détecterai plus visuellement les faux négatifs !
Oui, j’ai regardé sur tes exemples de floutage. J’ai décomposé une image floutée en Y, Cb et Cr. Effectivement, sur Cb et Cr, les carrés de flou font déjà 16x16. Accessoirement, il n’y a que dans Y qu’il y a de l’information. Le floutage des autres composantes ne paraît pas super utile.
Pour le nivellement, je pensais, après l’étape de DCT, sur l’étape de “quantization”(?), de ne garder que le premier coefficient correspondant à la valeur moyenne du carré. Mais mettre une forte compression JPEG doit à peu près revenir au même.
Sur ton principe de base, l’objectif est en tout cas d’éviter les calculs DCT aller et retour. Tu as une idée de ce qui prend le plus de temps dans ton traitement?
Là, il n’y a plus grand chose qui prenne du temps ou plutôt ça va bien assez vite pour nos besoins, vu que sur le serveur d’OSM-FR on doit être à 1 million d’image floutables par jour d’après mes tests en charge.
Et de mettre un smiley jaune qui couvre le visage au niveau du centre de la détectior (avec un flou derrière) ça aurait l’avantage de ne pas bloquer la détection de faux négatifs.
Pour les plaques, je suis sur qu’une idée pourrait être trouvée aussi. Par exemple les cadrillages des habits dans les anciennes BD belges, ceux qui ne changeaient pas d’angle malgré le mouvement des vêtements