Drônes de californie: essais d'analyse
Sommaire
- 1 Contexte et Généralités
- 2 Témoignage de Capitola
- 2.1 Présentation des images
- 2.2 Informations sur le matériel utilisé
- 2.3 Informations sur les photos (données EXIF)
- 2.4 Informations sur les données des images (au-delà de l'EXIF et du réel)
- 2.5 Reconstitution de l'histoire des données EXIF produites
- 2.5.1 Tout ce qui ne va pas dans ces données ...
- 2.5.1.1 1. La version des données exif (Exif version) produite est anormale
- 2.5.1.2 2. Les données sont enregistrées en "Big endian" (Exif Byte Order) ce qui est anormal
- 2.5.1.3 3. L'image JPG est enregistrée en "progressive DCT", là ou le Minolta produit des images en "Baseline DCT"
- 2.5.1.4 4. Données XMP: "Derived From Instance ID" et "Derived From Document ID" : UUID
- 2.5.1.5 5. Trace d'Exif Tool : données spécifiques à photoshop CS 2
- 2.5.1.6 6. Trace d'Exif Tool (2) : les données standard manquantes et les données importées
- 2.5.1 Tout ce qui ne va pas dans ces données ...
- 3 Vérification de la cohérence des photos avec la date, l'heure et le lieu indiqués
- 4 Reconstitution de la scène
- 5 Scénario probable
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.
- Les dessins avec des lignes courbes et des arabesques sont également très "tendance" sur le plan marketing et commercial, images
- 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.
- 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:
- Des photographes qui s'évanouissent dans la nature et tout état de cause font tout pour ne pas être reconnus
- Des témoignages/photos qui ne permettent pas d'identifier clairement le lieu de prise de vue
- 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,
- 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:
[Sur Flickr, rajman1977, le 20 mai 2007]
Cette semaine je rendais visite aux parents de mon fiancé à Capitola (nous étions en fait là-bas pour leur signifier notre engagement). Nous étions en train de dîner sur le porche de derrière lorsque nous remarquâmes cet "objet" qui avait l'air de planer dans le ciel.
(1, 2) L'appareil photo était resté après avoir été utilisé plus tôt et je l'attrapais et essayait d'en avoir des clichés nets. Il passa au-dessus du toit peu après, et
(3) je courus donc dans la rue devant la maison pour le suivre, en essayant d'en avoir d'autres clichés sans trop bouger (ce qui était plus face à dire qu'à faire).
(4,5) Il arriva alors plus bas au-dessus d'un poteau téléphonique, où je parvins à obtenir quelques autres clichés, avant qu'il ne finisse pas s'élever au loin assez rapidement.
(6) Je pensais qu'il était parti mais remarquais qu'il était toujours visible, et pris donc quelques autres photos.
A un moment une voiture s'arrêta pour regarder aussi. Personne n'avait une quelconque idée de ce que pouvait être cette chose mais cela effrayait visiblement tout le monde dans la voiture. Une fois qu'il fut parti ils me dirent d'appeler les journaux et s'en allèrent. Je suis pas sûr de qui d'autre pourrait l'avoir vu dans les environs dans là mesure où je ne vis pas ici, mais je suis certain qu'au moins quelques autres l'ont remarqué. C'était trop étrange et trop proche pour ne pas être remarqué. Une fois qu'il fut parti je retenais ma respiration et je pus difficilement empêcher mes mains de trembler durant à peu près l'heure qui suivit. Inutile de dire que nous n'avons parlé que de çà le restant de la nuit. Aucun d'entre nous n'arrive à imaginer ce que c'était (et cela a tout son sens, car le père de ma fiancée est ingénieur en mécanique).
Nous avons envoyé une copie des photos aux journaux mais n'en avons pas entendu reparler à ce jour. Je ne sais pas combien de temps prend ce genre de choses.
Il y a aussi des inscriptions sur cette chose, que je n'ai pas reconnues (et je lis l'anglais et l'hindi). Vous pouvez les voir sur quelques-unes des images.
Quoi qu'il en soit, j'ai créé ce compte Flickr pour les meilleures de ces images. Je n'ai aucune idée de ce qu'est cette chose et je les mets donc ici pour voir si jamais quelqu'un d'autre le voit.
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):
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 le ciel que de placer un 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 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.
- Si** ce cas était un hoax, alors 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.
Nous pouvons espérer qu'en se rapprochant du domaine un peu plus austère de celui du manipulateur d'information (l'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-
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/ <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.1-112"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:format>image/jpeg</dc:format> </rdf:Description> <rdf:Description rdf:about="" xmlns:xap="http://ns.adobe.com/xap/1.0/"> <xap:CreatorTool>Adobe Photoshop CS2 Windows</xap:CreatorTool> <xap:CreateDate>2007-05-20T13:04:39-07:00</xap:CreateDate> <xap:ModifyDate>2007-05-20T13:04:39-07:00</xap:ModifyDate> <xap:MetadataDate>2007-05-20T13:04:39-07:00</xap:MetadataDate> </rdf:Description> <rdf:Description rdf:about="" xmlns:xapMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#"> <xapMM:DocumentID>uuid:486E2C450D07DC119FD78ABD8FA3219B</xapMM:DocumentID> <xapMM:InstanceID>uuid:496E2C450D07DC119FD78ABD8FA3219B</xapMM:InstanceID> <xapMM:DerivedFrom rdf:parseType="Resource"> <stRef:instanceID>uuid:466E2C450D07DC119FD78ABD8FA3219B</stRef:instanceID> <stRef:documentID>uuid:B546BEBB0507DC119FD78ABD8FA3219B</stRef:documentID> </xapMM:DerivedFrom> </rdf:Description> <rdf:Description rdf:about="" xmlns:tiff="http://ns.adobe.com/tiff/1.0/"> <tiff:Orientation>1</tiff:Orientation> <tiff:XResolution>720000/10000</tiff:XResolution> <tiff:YResolution>720000/10000</tiff:YResolution> <tiff:ResolutionUnit>2</tiff:ResolutionUnit> <tiff:NativeDigest>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</tiff:NativeDigest> </rdf:Description> <rdf:Description rdf:about="" xmlns:exif="http://ns.adobe.com/exif/1.0/"> <exif:PixelXDimension>1600</exif:PixelXDimension> <exif:PixelYDimension>1200</exif:PixelYDimension> <exif:ColorSpace>1</exif:ColorSpace> <exif:NativeDigest>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 </exif:NativeDigest> </rdf:Description> <rdf:Description rdf:about="" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"> <photoshop:ColorMode>3</photoshop:ColorMode> <photoshop:ICCProfile>sRGB IEC61966-2.1</photoshop:ICCProfile> <photoshop:History/> </rdf:Description> </rdf:RDF> </x:xmpmeta>
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 faisant des opérations élémentaires au travers de Photoshop CS2, (sauvegarde, modification, création de nouveau fichier), si nous arrivions ensuite en "sommant les opérations" à retrouver les données EXIF finalement aujourd'hui disponibles.
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 cherché quelques photos prises en californie et au même format 1600x1200. Voici les 4 images à partir desquelles j'ai travaillé:
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 opérations et modifications induites sur ces fichiers exemple qui apparaissaient intouchés.
Ci-dessus: en vert, magenta et saumon : données ajoutées par Photoshop. Spécifiquement, en vert fluo, 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 images dérivées liées aux opérations effectuées (généralement, à partir de Photoshop CS 2):
1. Simplement, ouvre "SJ ROAD.JPG" et réalise l'opération directe "ENREGISTRER SOUS" (sans modifications):
2. Supprime les tags EXIF de photoshop depuis le fichier précédent avec ExifTool (commande: exiftool -Photoshop:All= "SJ ROAD CS2.JPG")
3. Ouvre le fichier "SJ ROAD CS2.JPG", dessine des trucs à l'intérieur et effectue la commande "ENREGISTRER-SOUS" "SAN JOSE ROAD CS2 - hello.jpg"
4. Ouvre le fichier précédent, "SAN JOSE ROAD CS2 - hello.jpg", efface ce qui avait été fait, effectue quelques dessins et la commande "ENREGISTRER-SOUS" "SAN JOSE ROAD CS2 - - world.jpg"
5 Crée un "NOUVEAU..." fichier, réalise un dessin, puis enregistre en jpeg progressif "NEW Hello World.JPG"
6. Importe 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
Tout ce qui ne va pas dans ces données ...
Si je résume ce que les tests précédent ont a nous dire, voici en quelques points:
1. La version des données exif (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
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 originaux de l'appareil que photoshop avait lui-même forcé pour les repasser à leur valeur originale. 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é certaines valeurs tel que l'encodage endian (Exif Byte Order) qui n'est pas importé. Or c'est extrêmement spécifique comme comportement!
Et c'est bien précisément le résultat que nous constatons dans les fichiers de Capitola (!)
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 :
- la situation météorologique,
- 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:
- Aller sur http://nomads.ncdc.noaa.gov:9091/ncep/NCEP
- Choisir "UNITED STATES ANALYSIS" ou "UNITED STATES WEATHER DEPICTION"
- Sélectionner la date: 17/05/2007
- 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"):
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.
- à 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:
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 :
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
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
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.
- 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 ?
- 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
Eléments | Crédibilité | Arguments |
Archétype du design | --- | |
Archétype des rencontres | --- | |
Photos | ---- | Données EXIF sur les paramètres de photo absentes. Images modifiées et enregistrées avec Photoshop CS2. 4 jours d'intégration possible entre le moment de la prise de vue et la production sous Photoshop. |
Témoin | --- | Aucune preuve de l'identité réelle. |