Imprimer

Merci de vous connecter ou de vous inscrire.
1 heure 1 jour 1 semaine 1 mois Toujours
Connexion avec identifiant, mot de passe et durée de la session

Loading

[elevenaugust]

Donc ici seront exposées les applications pratiques sur notre travail d'analyse comparative des photos des drones.

Vous trouverez la théorie dans un sujet séparé.

LA GENESE:
J'avais donc contacté dans un permier temps un chercheur américain qui avait établi un protocole mathématique permettant à partir de plusieurs images non retouchées de déterminer si elles provenaient du même appareil photo.
Après ses conclusions, je lui aie demandé s'il connaissait un chercheur capable de faire la différence, par calcul, entre une image CGI et une véritable photo.
Il m'a alors communiqué les coordonnées de ces trois chercheurs universitaires ayant réalisé ces travaux et les ayant commenté lors d'une conférence spécialisée à Innsbruck en 2006.
Les tentatives de contact par mail ayant été infructueuses, j'ai décidé d'essayer de mobiliser les chercheurs sur OM pour m'aider à faire le travail d'analyse qui nous intéresse par nous-même. (D'où mon appel aux bonnes volontés)

RESUME THEORIQUE:
La méthode de reconnaissance utilise deux grand critères de sélection:
visuel et texture.
Les critères visuels sont les suivants:
1)Le nombre de couleurs uniques
La CGI a tendance a avoir moins de couleurs uniques que les photographies. Le nombre moyen des couleurs uniques des photos est supérieur de 25% à celui des CGI.
2)La variation spatiale des couleurs
Les changements de couleur se produisent dans une plus faible amplitude en CGI qu'en photos.
3)La saturation des pixels
La moyenne et la variation de la saturation des pixels des CGIs est plus importante que celle des photos. D'une autre manière, les photos contiennent davantage de pixels insaturés que les CGIs.
4)L'intensité des bords
La surface rencontrée sur les bords dans les photos ont des propriétés matérielles et géométriques différentes,ayant pour résultat une intensité différente de la lumière réfléchie. Cependant, dans les CGIs les régions limitrophes tendent à différer dans leur tonalité et il n'y a pas de variation d'intensité.

Il y a ensuite la texture
La texture de l'image est extraite par les filtres de Gabor (wavelet)  http://fr.wikipedia.org/wiki/Filtre_de_Gabor et traitée par ces mêmes filtres mathématiques.
Puis la classification des résultats est faite par les algorithmes "du plus proche voisin" (K-NN)  http://fr.wikipedia.org/wiki/Recherche_des_plus_proches_voisins.

LE DEBUT DES TRAVAUX

A suivre....

[elevenaugust]

LES GROUPES D'IMAGES ETUDIEES
Par nécessité de distinguer les différents sujets d'études, j'ai créé six groupes d'images, 32 dans chaque groupe, qui seront soumis aux mêmes études visuelles et de textures et soumis au mêmes algorithmes:
GROUPE 1: les 32 images connues des drônes et des artefacts d'Isaac
GROUPE 2: 32 images de drones ne comportant que des pixels de drones
GROUPE 3: 32 images de drones ne comportant que des pixels de paysages autour des drones
GROUPE 4: 32 véritables photographies
GROUPE 5: 32 CGIs
GROUPE 6: Spécial Saladfingers
Les groupes 2 et 3 pourront permettre de différencier les images composites des autres.

Ensuite, il m'a fallu constituer une base de données d'images à étudier. Je me suis servi des mêmes sites de photos et de CGIs que ceux utilisés par les auteurs du texte.
GROUPE 1:

http://www.divshare.com/download/1963211-925

GROUPE 2:

http://www.divshare.com/download/2073938-6ac

GROUPE 3: idem
GROUPE 4:

http://www.divshare.com/download/1954810-250

GROUPE 5:

http://www.divshare.com/download/1963075-e3a

GROUPE 6:  [en cours] j'attend le feu vert de Saladfingers....

Deux chercheurs américains ont commencé à répertorier les pixels des images du groupe 4. (Peejaybee et StevenZ)
Les logiciels utilisés sont Ruby et ImageJ.
Les travaux sont encore en cours actuellement....

A suivre.....

[elevenaugust]

COMPTE-RENDU
14/09/07
StevenZ est le premier a rendre des résultats sur le critère n°1: le nombre de couleurs uniques. Son tableau:

Mes calculs:

Cependant,je pense qu'il y a un petit problème dans le décomptage des pixels;
Par exemple,l'image 1.bmp a 240.000 pixels, lorsque l'on soustraits tous les pixels de la rangée 1 à 9 inclues, il reste 24.135 pixels, qui devraient tous se retrouver dans la rangée 10 et au-dessus.
240.000-[(1*122.231)+(2*22.539)+(3*6.664).......]=24.135
Je pense que StevenZ fait une confusion entre les pixels et les couleurs.
L'article publié par les chercheurs nous indique que la formule est U= Ndifferent_triplet/Ntotal_pixels; où un "triplet" est un pixel <RGB>. PIl n'est pas question de couleurs différentes.
C'est le nombre total de triplets différents qui apparaissent 10 fois et plus pour chaque couleur différente.
Ainsi, le nombre "N" de triplets différents devrait être 24.135, ce qui fait U=24135/240.000=0.09625, ce qui est également ok avec notre assomption et plus proche des limites 0.01 et 0.2 définies par le tableau d'évaluation des chercheurs.
Il est possible cependant que je me trompe, et j'attend d'avoir les réactions de StevenZ ce soir pour conclure.

Peejaybee, de son côté, a commencé à "mouliner" les photos dans le programme Ruby avec un code prévu à cet effet. Les premiers résultats concernant la variation spatiale des couleurs des pixels (deuxième critère) sont attendus ce soir.

Edit:
Bon, effectivement, j'ai fait une erreur d'interprétation de la formule des chercheurs et StevenZ est venu éclairer ma lanterne.
Il s'agit en fait dans la formule U= Ndifferent_triplet/Ntotal_pixels uniquement de la proportion entre le nombre total de pixels rencontrés plus de 10 fois dans la même couleur(Ntotal_pixels) et le nombre total de couleurs rencontrées plus de dix fois.(Ndifferent_triplet) (je sais, c'est compliqué!) et non pas le nombre total de pixels de toute l'image
Le tableau doit cependant être refait pour rentrer ce nombre de pixels qui ne figure nulle part.
Je vous donnerais aussi un exemple pour que ce soit + clair.
Je m'y attelle dès que possible.

[elevenaugust]

15/09/07
StevenZ a repris toutes les photos du groupe 4 (photos "réelles"), les a moulinées dans son code de décomptage de pixels en fonction des couleurs et cela donne ce tableau:

Les valeurs qui nous intéressent sont sur la ligne "U", elles correspondent en fait à la richesse de la palette des couleurs de l'image.
Plus le chiffre est grand, plus la richesse des couleurs de l'image est élevée.
Nous avons une moyenne pour l'ensemble de ce groupe de (Somme des U/32)=0.0320

Saladfingers a accepté de m'envoyer ses créations originales afin de les rentrer dans le "groupe 6"; où elles seront traitées de manière identique aux autres.

[elevenaugust]

26/09/2007
Après un temps de flottements et d'hésitations, nous nous sommes finalement mis d'accord, StevenZ, Peejaybee et moi-même sur l'utilisation de JAVA (plus rapide que Ruby) pour la programmation des codes nécessaires au traitement des images.
Avec mon propre code, je trouve les mêmes résultats que StevenZ, (tableau du post précédent).
Nous pouvons donc valider ces résultats provisoires.
Le code pour la variation spatiale des couleurs est fait, nous allons le tester bientôt pour savoir si les résultats concordent avec ceux des chercheurs.
Nous travaillons sur le code pour les deux derniers critères visuels (saturation des pixels et intensité des bords).

Par ailleurs, nous allons pouvoir passer les images des autres groupes à travers le code JAVA pour les résultats du nombre de couleurs uniques donc.

Nous espérons pouvoir produire des tableaux dans quelques jours.

StevenZ travaille actuellement sur l'utilisation des filtres de Gabor dans le critère de texture discriminant les CGI des photos.

[Tartar]

Pas mal d'heures de boulot déjà 11/8!

Si il pouvait en sortir un bout de programme capable de détecter si  les images de drône sont réelles ou pas ce serait superbe, mais si il permettait de decter TOUS  les "fakes" à coup sur ce serait extraordinaire.

Cette recherche opiniâtre n'est donc pas vaine.
Merci.

[elevenaugust]

01/10/2007
Un nouveau venu a rejoint notre équipe de travail, il s'agit de "Littlehat", participant germanophone régulier au forum de Open Minds et féru de programmation JAVA.
Il a validé les résultats obtenus par Stevenz sur le "nombre de couleurs uniques" pour le groupe des images "réélles" en trouvant exactement les mêmes résultats, avec deux codes de conception différente.
Il travaille actuellement sur la constitution du tableau des résultats pour ce même critère, mais pour les CGIs.

Par ailleurs, j'ai commencé à créer la base de données nécessaire à l'évaluation des critères, à savoir 1000 photos (issues de la même source que les chercheurs) et 1000 CGI.
Lorsque cette base sera constituée, nous pourrons vérifier si les résultats des chercheurs se confirment ou pas, et par là-même nos postulats de base pour notre affaire.

Littlehat m'a proposé d'effectuer un "découpage intelligent" des drones pour évaluer les images selon nos critères, ce à quoi je lui aie répondu que ce travail était déjà en cours, grâce ici-même à Owni, qui a bien avancé dans ce travail fastidieux mais indispensable pour notre recherche.

[elevenaugust]

05/10/2007
Quelques premiers résultats tout à fait provisoires:
1)Nous avons terminé l'écriture des scripts JAVA pour les trois premiers critères de sélection visuels: "nombre de couleurs uniques"; "variation spatiale des couleurs" et "saturation des pixels".
Littlehat a fait un petit test sur 13 images de la base de données des catégories "Images réélles", "CGI" et "Drones" en appliquant le code "nombre de couleurs uniques" et "saturation des pixels"
Les résultats sont les suivants:
RICHESSE DE LA PALETTE DES COULEURS
IMAGES REELLES: moyenne 0.031977532498232236
IMAGES CGI: moyenne       0.017636049232452468
IMAGES DRONES: moyenne 0.01053531222494127
SATURATION DES PIXELS
IMAGES REELLES: moyenne 0.430286957597468
IMAGES CGI: moyenne       0.39174136166995266
IMAGES DRONES: moyenne 0.3673634003552656

Avec ces données, il convient de rester très prudent et de ne pas faire de conclusion hâtive, même si ces résultats très provisoires donnent les images des drones très proches des CGIs.
Avant de pouvoir émettre une quelconque conclusion, il faut étendre ce travail aux autres images-test, aux deux autres critères de sélection visuelle et valider la méthode par le passage des 1000 images "réélles" et des 1000 "CGI" de la base de donnée de référence à travers les scripts JAVA, comme l'ont fait les chercheurs.

2)Le travail le plus intéressant et le plus prometteur en terme de résultats et de probabilité de discrimination indiscutable est celui qui concerne le critère de sélection de la texture des images, implémenté par l'utilisation des filtres de Gabor.
Ce script vient de connaître une première ébauche par StevenZ, en trois scripts successifs:
IMPLEMENTATION DU FILTRE DE GABOR

Code: [Sélectionner]

package image.analysis;

import java.util.*;


public class GaborCalculator {

int s = 32; // filter matrix size - s x t
int t = 32;

int max_m = 5; // 5 scales
int max_n = 4; // 4 orientations

double U_l = 0.05; // lower frequency
double U_h = 0.8; // higher frequency
int a = 2; // (U_h/U_l)^(1/4), scale values 1,2,4,8,16

public GaborCalculator() {
}

/**
* This function returns filter matrix for given scale and orientation.
* There will be as many such matrices, as there are scales and orientation
* combinations (5x4=20). The size of the filter matrix was chosen to be 32x32.
* @param m - scale = [0..4]
* @param n - orientation = [0..3]
* @return
*/
public ComplexNumber[][] getFilterMatrix(int m, int n) { // m - scale, n - orientation
ComplexNumber[][] filterMatrix = new ComplexNumber[s][t];
for (int curr_s=0; curr_s<s; curr_s++) {
for (int curr_t=0; curr_t<t; curr_t++) {
filterMatrix[curr_s][curr_t] = calculatePhi(curr_s, curr_t,m,n);
//filterMatrix[curr_s][curr_t] = calculatePhi(curr_s - s/2, curr_t -t/2,m,n);
}
}
return filterMatrix;
}

/**
* This functions calculates Phi(x,y). Result is a complex number.
* @param x - Phi argument
* @param y - Phi argument
* @param m - given scale
* @param n - given orientation
* @return
*/
public ComplexNumber calculatePhi(int x, int y, int m, int n) {
int a_pow_m = 1;
for (int i=0; i<m; i++)
a_pow_m = a_pow_m * a;

double angel = n*Math.PI/max_n;
double _x = ( x*Math.cos(angel) + y*Math.sin(angel))/a_pow_m;
double _y = (-x*Math.sin(angel) + y*Math.cos(angel))/a_pow_m;
//double sigma_x=(a+1)*Math.sqrt(2*Math.log(2))/(2*Math.PI*a_pow_m*(a-1)*U_l); old version
double sigma_x = (a+1)*Math.sqrt(2*Math.log(2))/(2*Math.PI *(a-1)*U_h);
double sigma_y = 2*Math.PI*Math.tan(Math.PI/2/max_n)*
Math.sqrt(U_h*U_h/(2*Math.log(2)) - 1/(4*Math.PI*sigma_x*Math.PI*sigma_x));
sigma_y = 1/sigma_y;

double multiplier = 2*Math.PI*sigma_x*sigma_y*Math.exp((_x*_x/sigma_x/sigma_x + _y*_y/sigma_y/sigma_y)/2);
multiplier = 1/multiplier/a_pow_m; // Phi m,n = a^-m * Phi(x',y')

//angel=2*Math.PI*a_pow_m*U_l*_x; old version
angel = 2*Math.PI* U_h*_x;

return new ComplexNumber( multiplier*Math.cos(angel), -multiplier*Math.sin(angel)); // conjugated complex number
}

/**
* The main function, which calculates the whole features vector if
* Gabor filters. The size of the features vector is the number of
* combinations between scales and orientations: 5x4=20.
* Below goes explanation of what has to be done further
* (not implemented yet).
* Each element of the vector will be applied (convoluted) to each image pixel.
* After that, mean and deviation will be calculated for each feature
* for the whole image. So, after convoluting the whole image with
* this feature vector, there will be another vector of the same size 20,
* each element of which will be [mean, deviation] pair. This final
* vector of [mean,deviation] will get into storage during system
* training as a 'real', if convoluted image was real, or as a CGI,
* if convoluted image was a CGI. After such training on around 1K
* of CGIs and 1K of Real images, the system will be able to give an
* answer whether the image is real or CGI with a high probability.
* To do that the system will calculate the same feature vector of size
* 20 for the tested image, and will look for the closest feature vector
* in the trained storage, using the K-NN algorithm. If the closest
* vector is from Real image, then the questioned image is real, if
* it is from CGI image, then the questioned image is CGI.
* @return
*/
public List<ComplexNumber[][]> getFiltersForFeatures() {
List<ComplexNumber[][]> result = new ArrayList<ComplexNumber[][]>();
for (int curr_m=0; curr_m<max_m; curr_m++)
for (int curr_n=0; curr_n<max_n; curr_n++) {
System.out.println("Got filter " + curr_m + "" + curr_n);
result.add(getFilterMatrix(curr_m,curr_n));
}

return result;
}

COMPLEX NUMBER

Code: [Sélectionner]

package image.analysis;

import java.text.DecimalFormat;

public class ComplexNumber {

private double realis;
private double imaginalis;

// output number format
private static DecimalFormat dformat = new DecimalFormat("0.0000");

public ComplexNumber(double real, double img) {
realis = real;
imaginalis = img;
}

public double getImaginalis() {
return imaginalis;
}
public void setImaginalis(double imaginalis) {
this.imaginalis = imaginalis;
}
public double getRealis() {
return realis;
}
public void setRealis(double realis) {
this.realis = realis;
}

public double getModule() {
return Math.sqrt(getRealis()*getRealis() + getImaginalis()*getImaginalis());
}

public String getModuleStr() {
return dformat.format(this.getModule());
}

public String getRealisStr() {
return dformat.format(this.getRealis());
}

public String getImaginalisStr() {
return dformat.format(this.getImaginalis());
}

public String toString() {
return "Realis = " + dformat.format(this.getRealis()) + ", Imaginalis = " + dformat.format(this.getImaginalis());
}

}

ESSAI

Code: [Sélectionner]

public void testPrintFilter() {
GaborCalculator gabor = new GaborCalculator();
int m=3, n=2;
ComplexNumber[][] filter = gabor.getFilterMatrix(m,n);
for (int i=0; i<filter.length; i++) {
System.out.print(i+1+": ");
for (int j=0; j<filter[i].length; j++)
//System.out.print(filter[i][j].getRealisStr() + " ");
System.out.print(filter[i][j].getModuleStr() + " ");
System.out.println();
}

}
Ces codes ont été implémentés sur la référence de ces trois documents:
[1] J. Wu, M.V. Kamath, S. Poehlman, Detecting differences between photographs and computer generated images.

[2] D. Zhang, A. Wong, M. Indrawan, G. Lu, Content-
Based Image Retrieval Using Gabor Texture Features.

[3] B. S. Manjunath and W. Y. Ma., Texture features for
browsing and retrieval of large image data.

Le premier étant celui qui nous a servi comme étude de référence pour notre étude comparative.
Les formules et les valeurs pour la taille de filtre et d'autres paramètres ont comme source [3].  [2] copie le même processus avec des données expérimentales additionnelles. Dans [1] des filtres de Gabor sont utilisés pour la première fois comme outil de détection pour établir les différences entre le CGI et les vraies images. Ils déclarent la probabilité de 99% de détection de vraies images.
Les paramètres de filtre de Gabor dans [2] et [3] sont un peu différents (probablement une erreur mathématique). J'ai contacté un des auteurs pour clarifier ceci, mais n'ai pas obtenu de réponse, aussi aie-je choisi
[3] comme source principale, puisque les paramètres initiaux viennent de là.

Le travail continue sur plusieurs axes:
1) Littlehat continue le travail de génération des moyennes pour chaque critère visuel pour chaque groupe (32 images par groupe)
2)StevenZ parfait les scripts JAVA pour les filtres de Gabor et commence l'interprétation des images
3)Je continue la constitution des deux groupes de 1000 images (chacun) de référence pour valider les hypothèses de travail.

[Nemo492]

Etrait du site http://ovnis-usa.com à la date du 6/10 :

"11August signale des avancées dans le travail sur la détection des différences entre CGI et photos : Littlehat puis StevenZ viennent de publier quelques résultats intermédiaires, qui semblent très paradoxaux. En fait ils ne portent que sur l'analyse de 13 images quand il est prévu d'en traiter un millier par catégorie. Ceci me rappelle une déconvenue expérimentale récemment subie par un proche : des résultats obtenus en laboratoire après quelques dizaines d'expériences lui avaient d'abord fait penser que la progresion recherchée était d'ordre linéaire, et que le logiciel de traitement des données n'avait apporté que des rectifications de moyenne. En réalité, en poursuivant ses recherches, il s'est aperçu que la progression était exponentielle : des résultats trop peu nombreux au début n'avaient pas encore permis à la courbure de se révéler.

L'exemple ne s'applique pas strictement ici, mais il appelle à la prudence."

[elevenaugust]

N'oublions pas par ailleurs que sur les deux critères d'évaluation visuelle testés par Littlehat, celui de la "saturation des pixels" en lui-même et appliqué seul,  de l'aveu même des chercheurs, est d'une piètre qualité, ne donnant que des résultats très larges.
Seule la combinaison des quatres critères d'évaluation visuelle peut-être conclusive....

[elevenaugust]

09/10/2007
Voici les résultats du passage du groupe d'images "CGI" à travers le script JAVA déterminant la" richesse de la palette de couleurs"


La moyenne de "U" est:

• 0.0188 pour les CGI
• 0.0320 pour les photos

Ce qui nous donne une moyenne pour les photos >58.75%, soit bien plus grande que celle donnée par le chercheurs (photos>25% que les CGIs).
Les valeurs vont de

• 0.0545 à 0.0057 pour les CGIs
• 0.0715 à 0.0110 pour les photos

Cette petite étude est évidemment inconclusive; nous devons éprouver le système avec les 1000 photos et les 1000 CGIs, ainsi que l'on fait les chercheurs, avant de tirer des conclusions pour ce critère.
Il serait intéressant de tester des photocompositions comme celles de Saladfingers avec ce code...

[elevenaugust]

10/10/2007
Voici les résultats du passage du groupe d'images "DRONES" à travers le script JAVA déterminant la" richesse de la palette de couleurs"


La moyenne de "U" est:

• 0.0188 pour les CGI
• 0.0320 pour les photos
• 0.0067 pour les drones

Les valeurs vont de

• 0.0545 à 0.0057 pour les CGIs
• 0.0715 à 0.0110 pour les photos
• 0.0312 à 0.0010 pour les drones (0.0312 pour l'image prise par le téléphone cellulaire de Chad)

D'une manière générale et en comparant les résultats aux autres 32 images des autres groupes, nous pouvons dire que la richesse de la palette de couleurs pour les images des drones est très pauvre
Ceci est bien entendu toujours inconclusif.
En attente d'autres résultats...

[Seth]

Bonjour

Je suis nul en photo, mais j'ai une question ..
Puisqu'il s'agit (peut être) de matériel militaire, et que ces matériels sont souvent peints de teintes très uniformes ( vert kaki, brun terre ) , ne serait ce pas "naturel" que la palette de couleur soit étroite ?

[Seth]

Je voudrais rajouter..
Les analyses se sont principalement orientées vers les photos des drones, mais aux précialistes je pose la question: que pensez-vous des deux photos du "système antigravitationnel" qu'on trouve dans les téléchargements proposés par Isaac sur internet ( par exemple : http://isaaccaret.fortunecity.com/pacl-q486-photo-4-fullsize ) ?

[Nemo492]

S'il s'agit (peut être) de matériel militaire...

En effet, l'analyse comparative ne devrait-elle pas se faire avec des photos de tels matériels militaires ? Histoire de comparer ce qui est comparable...