Drônes de californie: essais d'analyse

Contexte et Généralités

Au départ, je n'ai guère "accroché" à cette histoire de drones, ceci car l'inspiration et le design m'apparaissaient d'inspiration très "terrestre".

Les arguments étant les suivants:

Archétype du Design

Que penser du fait que la police de caractère utilisée pour les drones de Californie corresponde à des katakanas « épurés » ? (à la fois dans les formes et dans le nombre). Le « hasard » n'est-il pas un peu gros ? Ceci s'accorde bien avec l’idée d'une projection humaine sur base de caractères connus comme nous l'observons souvent dans la SF contemporaine.

Ecriture Kligon utilisée dans Star Trek

Ecriture Aurek-Besh utilisée dans Star Wars

1. Les dessins avec des lignes courbes et des arabesques sont également très "tendance" sur le plan marketing et commercial, images
2. les formes marquées (flèches observables) à l'envers de ce que je considère comme pouvant représenter les technologies du futures. Cela mériterait un article, mais à mon sens l'évolution technique devrait nous rendre capables, de plus en plus, de nous jouer de la matière et de la manipuler en faisant fi des conventions intuitives à échelle humaine observable. Si l'on veut sur ce sujet, il suffit de se référer à certaines observations d'ovni pour voir à quel point la matière et la "réalité" peuvent être manipulées. Or là, rien de tel. Nous avons des formes qui semblent effectivement évoquer une fonctionnalité et donc sont conçus dans la droite ligne anthropoidéologique. Un dessinateur de mangas japonais aurait fait quelque chose de tout à fait similaire.
3. Incompatibilité avec l'ensemble des témoignages d'OVNI à ce jour, ce qui forme une classe à part.

Archétype du témoignage

Dans toutes les observations de drone, nous avons:

1. Des photographes qui s'évanouissent dans la nature et tout état de cause font tout pour ne pas être reconnus
   1. Des témoignages/photos qui ne permettent pas d'identifier clairement le lieu de prise de vue
2. Un ensemble de témoignages réalisés sur une aire géographique et une période déterminée compatibles avec l'idée de la réalisation d'un hoax par une personne ou groupe de personnes présentes dans la zone,
3. Des témoignages qui suivent étrangement un schéma assez similaire : des couples mariés ou en passe de l'être. L'élément "mariage" est toujours important,

Hyp: Donc, toutes choses très suspectes qui laissent penser à une manipulation humaine et dans la mesure où cela peut laisser l'impression que l'on s'attache à "vendre" un concept. Et c'est pourquoi je resterai très prudent.

Cependant...

... une proposition intéressante a émergée récemment. Qui rejoint la thématique d'U-Sphère et qui m'incite à accorder un regard (un peu) plus approfondi sur cette affaire: il existerait une corrélation entre l'observation des drônes et l'emplacement de la faille de San Andreas.

Hyp: l'option (?) possible serait alors de considérer les drônes commes des engins d'observation et qui utiliseraient "ordinairement" des techniques d'invisibilité optique. L'explication de l'aspect anthropomorphique tiendrait du fait que les engins seraient d'origine humaine, soit dans ce contexte hautement spéculatif, militaire.

Sans trop s'enfoncer en avant dans cette hypothèse, il m'est apparut intéressant de vérifier si un cas assez bien photographié résiste à l'analyse superficielle. Je n'ignore pas qu'un certain nombre de travaux ont déjà été réalisés sur le sujet, cependant je ne résiste pas à l'envie de vérifier moi-même certains détails.

Témoignage de Capitola

Allons-y ! Pour ceux qui auraient raté quelque chose, je rappelle l'histoire des prises de vue de Capitola qui constitue le 3ème témoignage de la série des drones du PACL. Je choisi ce témoignage car il est, en théorie, susceptible de nous conduire à des témoins directs, soit au contraire de démontrer qu'il y a une manipulation. Il s'agit du témoignage d'un dénomé "Rajman1977" auteur des photos:

Capitola: voir les différents témoignages originaux de Rajman ici (en anglais)

Présentation des images

Voici les 6 images prises à Capitola, dont les données EXIF sont curieusement bridées, (pour ne pas dire manipulées, voir ci-dessous):

(1) 17:41:11 - Curieusement la photo n'est pas centrée sur l'objet, mais celui ci cadré à droite. Drôle de façon de prendre une photo pour un phénomène qui devrait obnubiler le photographe. Ou sinon une précaution volontaire du photographe ? Intéressante, mais dans le viseur optique il ne devrait pas voir le mur (cf. ci-dessous).	(2) 17:41:34 (1)+23s - même remarque que précédemment. Le cadrage laisse apparaître un angle de la (d'une) maison	(3) 17:42:17 (2)+43s
(4) 17:42:58 (3)+41s	(5) 17:43:02 (4)+04s	(6) 17:44:37 (5)+95s

Origine des photos téléchargées: comme aujourd'hui elles ne sont plus disponibles sur Flickr, je les ai copiées du site de Didier de Plaige (OVNI USA).

Hyp: cela pourrait ressembler à un jeu de piste organisé, chaque photo laissant juste assez d'indices. Les photos juste sous les poteaux sont caractéristiques: pourquoi prendre les photos à cet endroit là précisément ? Est-ce quelque chose qui viendrait à l'esprit de quelqu'un observant dans le ciel quelque chose d'aussi rare et extraordinaire que de placer un tel obstacle dans sa vue?

Informations sur le matériel utilisé

Sous réserve de validité des données il s'agit d'un Minolta DiMAGE X, (informations détaillées ici), et dont voici quelques unes des principales caractéristiques qui vont nous intéresser:

• Appareil datant de juin 2002
• 1 960 000 pixels (2MPixels)
• Couverture du champ du viseur: 75%
• Taille du capteur optique: 1/2.7"
• Distance focale: 5.7 mm - 17.1 mm
• Distance focale équivalente à celle d'un appareil 35 mm: 37 - 111mm

Interrogations sur la couverture du champ du viseur

Le viseur sur cet appareil est optique. La couverture de champ par le viseur est de 75%, ce qui signifierait que les objets en extrême bord d'image ne sont pas vus au travers du viseur. Par conséquent, il serait intéressant de vérifier de quelle façon cette couverture du champ du viseur restreint la visée du témoin : bords latéraux verticaux/horizontaux et/ou les deux.

En l'occurrence, si le témoin n'observe effectivement que 75% des images obtenues au travers de son viseur optique, cela pourrait signifier que sa couverture visuelle effective était de 1385x1040 pixels, toujours par rapport aux images données.

C'est une chose intéressante à remarquer, car cela signifie que le témoin qui déjà, de façon très curieuse, n'avait pas centré correctement le sujet, était effectivement en limite de pouvoir l'observer : là, cela devient encore plus sensible, en particulier pour les trois premières photos:

Capteur CCD et ouverture angulaire

Si vous cherchez la correspondance entre la taille du capteur optique indiquée (commerciale) et sa taille physique vous aurez de quoi vous poser des questions. Par exemple ici, le capteur CCD est donné pour 1/2,7" de pouce: ne faites pas l'erreur de croire que cela correspond à sa diagonale!
Dans les faits, le grand coté mesure 5.3 mm soit environ 1/5". La diagonale est de 6,6 mm soit environ 1/4" et pas du tout les 1/2,7" annoncés... Ci-après, le tableau donne en fonction de la taille indiquée du capteur CCD les proportions dont il faut réellement tenir compte:

Cela vient tout simplement du fait que la grandeur commerciale est la diagonale du support du CCD, pas celle de la surface active, un peu comme dans les téléviseurs qui annoncent comme diagonale celle du carton d'emballage...

Donc pour résumer:

• Taille du capteur CCD (valeur "commerciale"): 1/2,7"
• Largeur du capteur CCD (effective) (l): 5,3 mm
• Hauteur du capteur CCD (effective) (h): 4 mm

A partir de là, afin de connaître la couverture angulaire, il faut disposer de la longueur de focale, or malheureusement, celle-ci est absente des données EXIF (voir ci-après). Nous avons simplement une plage de valeurs possible:

• Longueur de focale (f): 5.7 mm - 17.1 mm

Compte tenu du fait que l'angle d'ouverture a = 2*Atan(h/2f),

Nous obtenons simplement:

• ouverture angulaire verticale comprise entre : 38,66° et 13,34°
• ouverture angulaire horizontale comprise entre : 51,23° et 17,67°

Je vous propose de conserver ces éléments pour l'instant dans un "coin", en attendant de les réutiliser pour la reconstitution des scènes plus bas.

Informations sur les photos (données EXIF)

Les données EXIF attachées à ces photos, (vous pouvez lire les spécifications de la version 2.2 ici), comme nous le signalions plus haut sont pauvres en données. Est-ce du à la version du firmware (ce type d'appareil datant de 2002) ou bien les données ont-elles été sciemment effacées? Ce point va être vérifié ci-après.
Quoiqu'il en soit, en première approximation, la seule variation apparente dans les données entre les différentes photos prises semble tenir à l'heure de prise de vue et à la taille de la miniature générée.

Ci-dessus, entourées de rouge, les seules variations entre les photos. Dans la partie thumbmail, "compression 6" signifie que les thumbnails sont compressés au format JPEG tout simplement. Cela n'indique malheureusement pas le taux de compression utilisé.

Si et seulement si ce cas était un hoax, alors nous pourrions certainement penser que le terrain favori de l'auteur de ce hoax serait l'analyse et le traitement de l'image par des outils de composition graphique 2D/3D (c'est le point le plus dur -ou plus solide, au choix- de l'analyse). Aussi, nous pouvons espérer qu'en se rapprochant du domaine un peu plus austère de celui du manipulateur d'information (le vulgaire "informaticien"), il puisse y avoir des choses à vérifier et des points sur lesquels nous pourrions mettre plus facilement en défaut l'auteur présumé. Autant essayer de varier les terrains d'analyse !

La taille des miniatures (indiquée dans les données EXIF) est-elle conforme à la taille des photos ?

C'est la première question qui m'est venu à l'esprit. En d'autres termes, si nous recomposons des miniatures à partir des photos dont nous disposons, arriverons nous à un résultat en octets correspondant à un "poids" d'image conforme à celui indiqué dans les données EXIF ?
A voir... Car, comme nous le savons, le format JPEG est d'autant plus lourd que de l'information est présente dans la photo, donc la présence de ce drone devrait augmenter le poids des vignettes (thumbnails).

Dans l'hypothèse ou des photos de ciel bleu ont été prises et le drone aurait été rajouté après, il pourrait en effet s'observer une différence.

La réponse

Malheureusement, cela ne peut servir de moyen de vérification: un outil comme "Exifer" utilisé plus haut permet de visualiser également la vignette enregistrée avec la photo mais aussi de l'exporter.

Avec de tels outils, il est donc tout à fait possible pour un faussaire de modifier les données EXIF et d'aller jusqu'à changer la vignette associée à la photo pour la rendre compatible.

Ainsi, ci-dessous, j'ai extrait les vignettes des 6 photos dont nous pouvons constater au passage qu'elles sont plus fortement dégradées. Le format est bien entendu, toujours du JPEG. La taille des vignettes (en pixels) est de 160x120 -ce qui ne correspond en rien à la taille de l'écran LCD de 110 000 pixels utilisé sur cet appareil, si l'on cherchait une corrélation quelconque par ce biais-

(1) thumb: 3 473 octets originale: 548 064 octets Ratio: 157	(2) thumb: 2 002 octets originale: 462 564 octets Ratio: 231	(3) thumb: 1 389 octets originale: 277 177 octets Ratio: 199
(4) thumb: 2 868 octets originale: 466 017 octets Ratio: 162	(5) thumb: 2 409 octets originale: 388 766 octets Ratio: 161	(6) thumb: 3 233 octets originale: 451 241 octets Ratio: 139

Autres questions

Les différences de ratio (poids de l'image "originale" divisé par le poids du thumbnail) entre les photos sont surprenantes (de 140 à 230). Pourquoi de tels écarts ?

Certains seuils au niveau des échelles de granularité composant les motifs des images sont peut-être franchis, ce qui provoque des écarts. Pour en avoir le coeur net, il faudrait partir des images originales sous photoshop et les réduire de la même façon [=>]

Informations sur les données des images (au-delà de l'EXIF et du réel)

Appliquons un traitement de choc et dégainons "notepad" afin d'observer ce que contiennent ces images et que les données Exif ne nous disent pas:

Le décryptage est "simple" lorsque l'on connait la signification des zones:

• le fichier commence par la description du format, (JFIF - JPEG File Interchange Format),
• immédiatement suivi, des données EXIF,
  • ... à l'intérieur desquelles, nous trouvons insérées les données d'une image miniature toujours au format JFIF. Ces données sont la copie exacte des vignettes extraites ci-dessus (voir le fichier de la vignette).
• Après les données de la vignette, suit quelque chose de plus étonnant : du code XML d'une application tierce (!) Et pas de n'importe quelle application puisqu'il s'agit d'Adobe Photoshop CS2.
• Ensuite le fichier se poursuit sur le bloc de données de l'image principale proprement dite.

Il devient là évident que les photos ont subit une manipulation au travers de Photoshop.
Voyons ce que ces meta-données ont à nous dire dans leur plus grand ensemble.

Que pouvons-nous comprendre des informations tierces stockées dans les images ?

Ci-après une partie des données lisibles de la photo "Capitola 13".

http://ns.adobe.com/xap/1.0/


   http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      http://purl.org/dc/elements/1.1/">
         image/jpeg
      
      http://ns.adobe.com/xap/1.0/">
         Adobe Photoshop CS2 Windows
         2007-05-20T13:04:39-07:00
         2007-05-20T13:04:39-07:00
         2007-05-20T13:04:39-07:00
      
      http://ns.adobe.com/xap/1.0/mm/" 
            xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#">
         uuid:486E2C450D07DC119FD78ABD8FA3219B
         uuid:496E2C450D07DC119FD78ABD8FA3219B
         
            uuid:466E2C450D07DC119FD78ABD8FA3219B
            uuid:B546BEBB0507DC119FD78ABD8FA3219B
         
      
      http://ns.adobe.com/tiff/1.0/">
         1
         720000/10000
         720000/10000
         2
         256,257,258,259,262,274,277,284,530,531,282,283,296,
301,318,319,529,532,306,270,271,272,305,315,33432;CBB0F357681357EA5402D2D4194E4709
      
      http://ns.adobe.com/exif/1.0/">
         1600
         1200
         1
         36864,40960,40961,37121,37122,40962,40963,37510,
40964,36867,36868,33434,33437,34850,34852,34855,34856,37377,37378,37379,37380,37381,37382,37383,37384,37385,37386,37396,
41483,41484,41486,41487,41488,41492,41493,41495,41728,41729,41730,41985,41986,41987,41988,41989,41990,41991,41992,41993,
41994,41995,41996,42016,0,2,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,22,23,24,25,26,27,28,30;B18766B2D943F46AC2A573FD1C3E642F

      
      http://ns.adobe.com/photoshop/1.0/">
         3
         sRGB IEC61966-2.1
         
      
   

Il s'agit de données au format "XAP".

XAP est un sigle abandonné par Adobe qui signifie "eXtensible Authoring Publishing" aujourd'hui devenu XMP "eXtensible MetaData Plateform". La philosophie sous-tendue là derrière consiste en la description de meta-données métier (multimedia) qu'ajoute Adobe à ses documents. Un peu à la façon des données EXIF, cela permet d'ajouter des informations qui permettent de mieux comprendre le contexte de production des documents.

La documentation des tags est disponible ici chez Adobe qui soutient (et pousse) cette standardisation. Concernant les images JPEG, Adobe mélange allègrement les genres en appelant les données qu'il produit, données "XMP-exif". En fait les données XMP sont incluses dans les données Exif, mais seuls des outils spécifiques peuvent les lire et les reconnaître.

Par conséquent, j'ai essayé différents petits logiciels pour lire ces meta-données directement tels que iTag, Kalimages ou FastPictureViewer mais sans succès.

Finalement, c'est exiftool qui m'a permis d'extraire toutes les informations XMP (il extrait également les données Exif).

Meta-Données "XMP-Exif"

Voici un tableau consolidé des meta-données Exif et XMP des différentes images, créé à partir des données extraites par exiftool.

• Au passage, il serait intéressant d'examiner de près les uuid. Notamment pour ceux nommés 'Derived From Document ID'. La date est-elle utilisée pour générer l'uuid? Que peut-on connaître du document source grâce à l'uuid?

Un autre outil permet d'examiner de plus près les données JPEG, et en particulier de retrouver en fonction des caractéristiques de la compression appliquée par le matériel ou logiciel source utilisé. Ce qui s'avère particulièrement utile pour les photos éditées à posteriori : il s'agit de JPEGsnoop

Lorsque utilisé sur l'image "Capitola13_large", voici ce que nous dit la fin du rapport :

*** Searching Compression Signatures ***


   Signature:           0166B0BC0B82C8233430BF67FA31C829
   Signature (Rotated): 0166B0BC0B82C8233430BF67FA31C829
   File Offset:         0 bytes
   Chroma subsampling:  1x1
   EXIF Make/Model:     OK   [MINOLTA CO.,LTD] [DiMAGE X]
   EXIF Makernotes:     NONE
   EXIF Software:       OK   [V100-02]



   Searching Compression Signatures: (3314 built-in, 0 user(*) )


   EXIF.Make / Software              EXIF.Model                        Quality        Subsamp Match?
   
-------------------------   -----------------------------------   ----------------   --------------
   [Adobe Photoshop          ]                                    [Save As 10      ]


ASSESSMENT: Image is very likely processed/edited

Reconstitution de l'histoire des données EXIF produites

Je me suis dit qu'il serait aussi intéressant de rechercher d'autres images prises à partir d'un Minolta DiMage X (firmware v100-02) et de comparer les données, de pointer les différences. Puis, d'observer en effectuant des opérations élémentaires au travers de Photoshop CS2, (sauvegarde/modification/création de fichier), si nous arrivions au travers d'une suite de ces opérations à retrouver les données EXIF aujourd'hui constitutives des fichiers de Capitola.

Il est en effet assez simple de rechercher sur flickr des photos prises avec un type d'appareil photo identique. Nous nous pouvons par exemple chercher les photos prises en Californie avec un Minolta DiMage X : http://www.flickr.com/search/?q=california&cm=minolta%2Fdimage_x

J'ai ainsi récupéré quelques photos prises en Californie et au même format -1600x1200-. Voici les 4 images (pauvres victimes numériques) à partir desquelles j'ai travaillé:

• HELICOPTER.jpg
• CATS.jpg
• SAN JOSE ROAD POLE.jpg
• SAN JOSE ROAD.jpg

Le travail ci-après de reconstitution a été assez long, en termes de consolidation et de vérification de l'information. Il présente les modifications dans les données EXIF appliquées à ces fichiers au départ "intacts" ne présentant - à priori - aucune autre donnée que celles enregistrées par l'appareil photo Minolta Dimage X.

Ci-dessus: en vert, magenta et saumon : données ajoutées par Photoshop. Spécifiquement: en vert fluo, données directement liées à Photoshop, en magenta données XMP, en saumon données ICC. En noir données effacées par ExifTool. Autres couleurs: données spécifiques (considérés ici comme des marqueurs intéressants) Si vous le souhaitez, vous pouvez également directement télécharger le fichier XLSX associé: Exif comparison.xlsx - attention toutefois, c'est un document office 2007 !-

Et voici les opérations élémentaires effectuées à partir de l'image "SAN JOSE ROAD.JPG" (généralement, sous Photoshop CS 2):

1. Ouvrir "SJ ROAD.JPG" (SJ=San José) et ENREGISTRER SOUS "SJ ROAD CS2.jpg" (sans autres modifications):

• SAN JOSE ROAD CS2.jpg

2. Supprimer les tags EXIF Photoshop de "SJ ROAD CS2.jpg" (fichier précédent) avec ExifTool (commande: exiftool -Photoshop:All= "SJ ROAD CS2.JPG")

• SAN JOSE ROAD CS2-del.jpg

3. Ouvrir le fichier "SJ ROAD CS2.JPG" et dessine des trucs à l'intérieur. Puis, effectuer la commande ENREGISTRER-SOUS "SAN JOSE ROAD CS2 - hello.jpg"

• SAN JOSE ROAD CS2 - hello.jpg

4. Ouvrir le fichier précédent, "SAN JOSE ROAD CS2 - hello.jpg", effacer ce qui avait été fait, effectuer quelques dessins et puis la commande ENREGISTRER-SOUS "SAN JOSE ROAD CS2 - - world.jpg"

• SAN JOSE ROAD CS2 - - world.jpg

5 Créer un NOUVEAU... fichier, réaliser un dessin, puis ENREGISTRER (jpeg progressif) "NEW Hello World.JPG"

• NEW - Hello World.jpg

6. Importer des données EXIF du fichier "SJ ROAD.JPG" sur le précédent fichier en excluant les paramètres liés à la prise de vue (commande: Exiftool "SJ ROAD.JPG" -exposuretime= -fnumber= -exposurecompensation= -maxaperture= -Value= -Aperture= -imagesize= -shutterspeed= -focallength= -lightvalue= -TagsFromFile "NEW - Hello World + EXIF.jpg")

• NEW - Hello World + EXIF.jpg

Tout ce qui ne va pas dans ces données ...

Si je résume ce que les tests précédents ont a nous dire, voici en quelques points:

1. La version des données exif (Tag Exif version) produite est anormale

Ce Tag est ajoutée au moment de la constitution de la photo. Ensuite, Photoshop CS 2 ne le connaît pas: de fait, il l'ignore (il ne l'ajoute pas ni ne le modifie).

OR, le Minolta Dimage X est censé produire des données exif marquées en version 0210 non pas 0220.

Ce problème s'explique difficilement. Soit un autre appareil photo a été utilisé (une version ultérieure du Dimage X, le X1 par exemple, soit la version a été retouchée par une application tiers que je ne n'identifie pas, soit par l'auteur lui même (à quelles fins ?), soit l'auteur utilisait un Dimage X avec un firmware spécial. Cependant la version de ce dernier est conforme à celle d'autres photos prises avec un Dimage X. Quoiqu'il en soit il y a une anomalie curieuse là derrière.

2. Les données sont enregistrées en "Big endian" (Exif Byte Order) ce qui est anormal

Voilà là aussi un point totalement en contradiction avec des données produites par le Dimage X. Puisque cet appareil photo crée des images en "Little endian". Ce n'est pas une donnée qui peut souffrir d'exception puisque cela est liée à l'architecture du processeur utilisé. A savoir que, "Big endian" correspond à une lecture des octets de gauche à droite et "Little endian" de droite à gauche. (et les fichiers sont enregistrés de telle sorte à faciliter le travail de lecture des "mots" qui peuvent faire plusieurs octets).

Ces changement ne peuvent être réalisés (c'est radical) que par la création d'un nouveau fichier: c'est à dire que l'on ne travaille pas sur un fichier original, même transformé de façon cosmétique, puisque c'est la façon même d'enregistrer l'information qui a été modifiée.

Des tests réalisés, montrent que ce changement est effectif si l'on crée un nouveau document à partir de Photoshop CS 2 et que l'on développe son travail à partir de celui-ci. En effet, par défaut, Photoshop travaille en "Big endian".

Autre indice de la création d'un nouveau fichier en amont: l'utlisation du format "Media-Relative Colorimetric" (Encoding Process) ajouté lorsque l'on crée un nouveau fichier alors que si nous réalisons des "enregistrements sous" seuls le processus d'encodage serait noté "Perceptual".

3. L'image JPG est enregistrée en "progressive DCT", là ou le Minolta produit des images en "Baseline DCT"

Le choix de ce mode pour les jpeg est effectué lors de l'enregistrement du fichier. Au départ, il a été imaginé pour des images lourdes que l'on devait afficher sur le web et qui permettaient de disposer d'un affichage progressif, (plus pixelisé) dans l'attente que l'ensemble des données soient chargées. En pratique, ce format est de moins en moins utilisé; et le minolta enregistre en "Baseline DCT". L'explication serait que l'auteur a souhaité enregistrer en "progressive DCT" pour flickr: il aurait ainsi pu se justifier de passer par Photoshop. Dans cette hypothèse, c'est cependant bien inutile...

4. Données XMP: "Derived From Instance ID" et "Derived From Document ID" : uuid:F76636E8DE11DD11A23AF05E0180AD62 et uuid:E6C61270DF11DD11A23AF05E0180AD62

Comme noté plus haut, ce qui semble se confirmer c'est que les données "Derived From Instance ID" et "Derived From Document ID" sont similaires au départ. Par exemple, lors de la création d'un premier document photoshop ou lors de la première sauvegarde d'un document JPG sans meta-données XMP.

Puis, lors de modifications ultérieures (sauvegardes sous d'autres noms), ces deux champs divergent profondément pour refléter des identifiants uniques (au départ, en réalité, seul le premier octet change). Cela semble être le signe que ces document font partie partie d'une 2ème génération de document JPG générée à partir de photoshop.

5. Trace d'Exif Tool : données spécifiques à photoshop CS 2

Il est à peu près certain que les opérations sous Photoshop ont été volontairement masquées. En effet, toutes les données spécifiques à photoshop ont été supprimées (en vert fluo dans le tableau ci-dessus), sauf celles qui ont été... rajoutées (spécifiquement) par Photoshop, notamment les données XMP. Cela est *impossible* sans l'usage d'un outil spécialisé.

Précisément, ExifTool est capable, par une commande simple, d'effacer précisément les données photoshop qui manquent aujourd'hui au fichier EXIF. Ces tags (cases marquées en noir dans le tableau ci-dessus) sont les suivants:

• Application Record
• version
• Caption Abstract
• Copyright Flag
• Displayed Units X
• Displayed Units Y
• EGlobal Altitude
• Global Angle
• Photoshop Format
• Photoshop Quality
• Photoshop
• Thumbnail
• Progressive Scans

La commande -simplissime- est la suivante:

exiftool -Photoshop:All= "myFile.jpg"

6. Trace d'Exif Tool (2) : les données standard manquantes et les données importées

Si ExifTool a été utilisé pour supprimer des données, il peut aussi avoir été utilisé pour ajouter des données. Une anomalie déjà constatée par certains (comme sur le forum openmind) est qu'il manquait des informations spécifiques au paramètres de prise de vue. Précisément repris, les Tags manquants par rapport à un fichier "normal" créé à partir d'un Minolta DImageX sont les suivants:

• Exposure Time
• F Number
• Exposure Compensation
• Max Aperture
• Value
• Aperture
• Image Size
• Shutter Speed
• Focal Length
• light Value

(sans compter Maker Note Version et Minolta Camera Settings 2 écrasés par photoshop).

Ces tags manquants auraient pu probablement créer des contraintes supplémentaires sur la conception d'images avec des éléments "artificiels". C'est une raison de plus pour penser que les données EXIF ont bel et bien été manipulées.

Mais plus encore:

Il existe précisément une commande ExifTool permettant de copier des paramètres Exif liés à une image sur une autre, ici en omettant les tags précédents:

Exiftool "Capitola original.jpg" -exposuretime= -fnumber= -exposurecompensation= -maxaperture= 
-Value= -Aperture= -imagesize= -shutterspeed= -focallength= -lightvalue= -TagsFromFile   "Capitola filtered.jpg"

Or, ce qu'il y a de très intéressant de constater c'est que cette même commande rétabli certains paramètres EXIF de l'appareil que photoshop avait lui-même forcé pour les repasser à leur valeur originale (fixées par l'appareil photo). Par exemple, le tag EXIF Software normalement forcé par Photoshop à "Adobe Photoshop CS2 Windows", mais repassé à "V100-02" par ExifTool.

Or, ExifTool, et c'est là sa signature, ne rétabli pas tous les tags. Probablement du à un bug, il laisse aussi inchangé certains tags tel que l'encodage endian (Exif Byte Order) qui n'est pas importé. Or c'est un comportement extrêmement spécifique précisément observé dans les fichiers de Capitola (!)

Synthèse des opérations reconstituées à partir des données EXIF

Voici, de fait, l'histoire possible reconstituée des données EXIF:

Vérification de la cohérence des photos avec la date, l'heure et le lieu indiqués

Le seul moyen de vérifier la cohérence de ces informations consiste à se baser sur les rares éléments exogènes dont nous disposons, soit :

1. la situation météorologique,
2. la position du soleil dans le ciel,

et de les comparer avec les données présentées par les photos ceci à la date, heure et lieu proposés.

Les données de référence que nous retenons, suivant les informations fournies par le témoin sont les suivantes:

• Date et Heure locale: le 16/05/2007 de 17:41:11 à 17:44:37 (-7H TU)
  • soit Date et Heure TU: le 17/05/2007 de 0:41:11 à 0:44:37 TU
• Position, à partir du centre ville supposé de Capitola :
  • Latitude: 36.9785° (36°58'42.60"N)
  • Longitude: -121.953° (121°57'10.80"O)

1. Situation Météorologique

Le "National Oceanic and Atmospheric Administration" (NOAA) et le "National Climatic Data Center" nous permettent de disposer de données via un système d'archives consultable en ligne: le "Service Records Retention System" (SRRS)

L'heure et de référence que nous choisissons sont celles de la première photo (le 17/05/2007 à 0h41 TU). Puis, pour télécharger les cartes météorologiques:

1. Aller sur http://nomads.ncdc.noaa.gov:9091/ncep/NCEP
2. Choisir "UNITED STATES ANALYSIS" ou "UNITED STATES WEATHER DEPICTION"
3. Sélectionner la date: 17/05/2007
4. Les cartes météo sont classés par tranches horaires au rythme d'environ 8 cartes par jour.

Voici les cartes météo telles proposées pour la région centre-ouest ("United States Surface Central_West Analysis"):

Situation générale aux USA. Le 16/05/2007 01h41 TU, soit 1h minutes après

Situation générale aux USA. Le 17/05/2007 22h42 TU, soit 1h59 minutes avant

Symbole météo principal

Légende associée

Le 17/05/2007 01h31 TU, soit 50 minutes après

Le 16/05/2007 22h30 TU, soit 2h11 minutes avant

Interprétation

La précision à 50 minutes près est intéressante. En zoomant sur la zone de capitola, et à partir de la carte de 01h31 voici ce que nous obtenons:

Nous constatons que le ciel est donné pour clair (couverture nuageuse nulle) quelle que soit la direction autour de Capitola: au nord dans la baie de San Francisco, à l'est jusqu'au Nevada, ou encore plus au sud en direction de la station météo de Watsonville. Ceci 2h11 avant ET 50 minutes après la prise des photos. La couverture nuageuse au dessus de la mer, quand à elle ne semble pas être donnée (x).

Il apparait, de plus, souffler vent un modéré en direction de l'Ouest-Nord-Ouest (292°).

Ces informations apparaissent donc compatible avec les photos du drone présentant un ciel dégagé.

Une autre manière "élégante" de confirmer la nature du ciel jour là, consiste à rechercher des photos prises le même jour dans la région de Capitola. Par exemple :

• à Watsonville,
  • la photo DSC00674 prise à 14:38:25, 3 heures avant les images du drone, est particulièrement intéressante en ce qu'elle montre le même type de ciel. C'est à dire, clair avec des cirrus épars.

14:38:25. Watsonville. (ce sont des morceaux de pain accrochés !)

• à Big Sur un site touristique situé au sud de Capitola et en bord de mer, non loin de Watsonville également:
  • Il y a par exemple une série de photos prise 25 minutes après les images du drone, qui montre un ciel toujours clair et dont voici la deuxième:

18:07:53. Big Sur.

Ces deux exemples sont particulièrement intéressants car les données EXIF permettent de vérifier les informations. Des photos ont également été prises à Capitola ce jour là, dans le milieu d'après midi par exemple :

Capitola le 16 mai 2007. Cependant les informations EXIF ne sont pas disponibles pour cette photo. et nous n'avons pas l'heure. En se basant sur l'ombre du personnage, nous pouvons déduire l'élévation du soleil qui serait de approximativement 45°. Cela donnerait entre 15h-16 heures locales.

De cet ensemble de données, il apparait que le ciel est en cohérence avec celui des photos du drone et que des photos ont effectivement pu être prises cet après midi du 16/05/2007 à Capitola. Reste à savoir si l'image ajoutée du drone est en cohérence.

2. Position du soleil dans le ciel

Eclairage de la Terre et position de Capitola le 17/05/2007 à 0:41 TU (WinStar)

Toujours sous réserve d'un étalonnage correct de l'appareil photo, la position relative du soleil donnée à 0h41 TU le 17/05/2007 pour le centre ville de Capitola (Latitude: 36.9785° (36°58'42.60"N) / Longitude: -121.953° (121°57'10.80"O)) est la suivante:

• Azimut  : 273°58'43"(NOAA) 273°58'39" (Stellarium)
• Elevation: 27°44'24" (NOAA) 27°43'12" (Stellarium)

Curieusement, il existe un petit écart entre la donnée fournie par l'outil du NOAA et Stellarium. A noter cependant que l'outil du NOAA n'est précis pour ce qui concerne la latitude et la longitude qu'à la seconde près (l'arrondi est pris) alors que Stellarium lui ne permet carrément pas de régler les secondes (positions géographiques)! - disons que cela passe par une carte du monde sur laquelle un curseur doit être déplacé à la souris: pas très précis -

Nous allons maintenant procéder à une vérification de la compatibilité de cette position du soleil dans le ciel par rapport aux photos et pour cela nous allons devoir procéder à une reconstitution des scènes de prise de vue.

Reconstitution de la scène

Je vous propose de scinder les photos en 4 scènes, c'est à dire en regroupant les photos prises à peu près du même endroit, c'est à dire superposables.

Cohérence des photos avec la végétation

Arbres de Californie

Vérification de la compatibilité avec la situation météorologique du 16/05/2007 à Capitola

Vérification de la compatibilité avec l'éclairage

Scénario probable

Ce qui veut dire que l'on peut établir le scénario suivant:

• Les photos auraient été créées le 16 mai 2007 entre 17:41:11 et 17:44:37 (3 minutes 26 secondes) heure locale, si tant est que l'appareil photo était à l'heure,
• Puis retouchées, dans le désordre, le 20 Mai 2007 via Adobe Photoshop CS2 entre 13:04:39 et 13:59:32.
  • Pas simplement ouvertes, mais bel et bien enregistrées sur une plage de 54mn53s avec ce qui apparait comme "une pause" de 43 minutes entre les 4 premières et les deux dernières images: pas le temps de faire des masses de retouches, *à moins que* le travail ait été effectué les jours précédents ?
    • Question posée: qu'a t-on le temps de faire en 13 à 24 secondes sous Photoshop ? Réponse à vue de nez : sauvegarder la photo dans un format, le temps de saisir le nom, répondre aux boîtes de dialogue, puis en ouvrir une autre.
• Puis ces images ont été publiées via un message sur CraigList le même jour à 15h18.

Questions restant posées

• ouverture angulaire de l'appareil photo ?

• A quel type d'arbre avons nous affaire sur la photo ?
  • (1) (2) :
  • (1)

Tableau de synthèse