Unistellar Evscope : Les nouveautés de App 2.0…

Tout récemment (juin-juillet 2022), Unistellar a “libéré” la version 2.0 de leur application de contrôle. Et le moins que l’on puisse dire, c’est qu’elle a surpris ses utilisateurs… Moins stable (personnellement, je dois systématiquement la redémarrer en observation), moins évidente à utiliser (trop de menus et sous-menus), plus lente et les quelques améliorations (parfois bienvenues) ne compensent pas actuellement les défauts…
C’est un “renew” sans ajout réel (sur la qualité, l’export d’image, les problèmes wifi, etc…), mais surtout : sans “way back” (un air de Windows 8 ! )

Bref : espérons une 2.1 rapidement !

Inventaire rapide :

  • Pas la même approche en terme de “menu” et “gestion”
  • Pas la même méthode pour démarrer une session
  • Plus d’approche de présentation “temporelle” des objets du catalogue (visibles, bientôt visibles, disparus) et de catégories
  • Pas la même façon de “diriger” le tube
  • Des problèmes systématique de synchro GPS sur Android (jamais eu avant, tant sur iOS que Android), semble ok sur iOS.
  • Des “pertes” de connexion et blocage du tube (alors qu’on est proche de lui)
  • Des problèmes de fin des sessions (pas d’arrêt, blocage du tube, etc…)
  • Pas la même manière de “capturer” une image
  • Tous les termes “repères” changent, assez perturbant… (ex : “dark” devient “calibration”, ce qui n’a rien à voir…)
  • Des informations élémentaires deviennent illisibles (ex: au lieu d’un “60% de batterie“, répandu chez 4 milliards de personnes, on a un “moins du trois-quart de batterie” !
    Je n’ai pas testé, mais reçoit-on “trop tard” au lieu de “0%” ? )
  • Des opérations jadis organisées simplement dans un seul écran (version 1.5 et 1.6) sont explosées en plusieurs écrans et menus, obligeant à “sauter” d’un menu à l’autre, ou d’une options à l’autre…
  • Une “vision” de la capture (taille écran et comportement) assez perturbante selon les menus…
  • De nouvelles fonctionnalités :
    • Vitesse lente, utile cela aide, mais une réactivité lente aussi…
    • Un menu général sur la configuration
    • La configuration de l’export d’image, permettant les deux modes en simultané : utile
    • Un nouveau graphisme des boutons (qui exige de mettre ses lunettes, désormais !)
    • L’affichage d’un objet du catalogue revu (constellations, coordonnées)
    • Un menu science revu (mais on s’interroge sur un bouton restant sans explication)
    • De nouveaux objets (il parait, mais l’ordre présenté étant changé, difficile de juger)
    • Un nouveau menu de “diaporama” des images avec des informations supplémentaires
  • Et visiblement : des métadonnées dans les images !
    (le sujet qui va nous occuper ici)

Comme les informations, manuels et autres guides livrés avec le tube ne décrivent (évidemment) pas ce nouveau système, les “anciens” utilisateurs sont submergés de questions des débutants… (et à raison…). Pour ceux (dont moi) qui ont vanté sa simplicité d’utilisation, on finit par le regretter !

Dans cette page, je vais m’intéresser à une modification importante : les formats d’images… Comme déjà évoqué, un besoin criant de la première version était de pouvoir “exporter” et “ranger” ses images facilement.

Deux nouveautés de la version 2.0 :
– On peut sauver DEUX images en même temps (le format “Full” et le format “Crop”), ce qui simplifie pas mal la gestion… Impact perso : il faudra adapter les programmes déjà présentés, mais comme le “nom” des images est désormais logique, cela simplifie encore plus !
– On dispose visiblement apparemment de metadata dans les images !
(Ouf, enfin !), car dans le nouveau menu d’affichage :

Visualisation des images “améliorés”

On retrouve le “nom” des objets observés lors de l’affichage, donc, on a apparemment enfin rempli des fields Exif des images…
Et il suffirait donc de les lire pour (enfin) disposer des informations et “ranger” ses images en les renommant dans le mode : <UTC>_<title>_<exposure>_<LocLat>_<LocLong>.png

Du moins, c’est ce que j’espérais…. Mais, hélas, on est plutôt dans la personnification du concept Shadok bien connu :

Jugez-en par vous-mêmes…

Les nouvelles métadonnées…

Tout d’abord, puisqu’on les a, pourquoi ne pas sauver directement les images avec le nom de l’objet ??? Et tout ce qui suit serait inutile…

Format PNG/V1.6 – Android

Prenons une “ancienne” image “full” (version 1.6) et cherchons les EXIF standards…

ExifTool Version Number : 11.99
File Name : eVscope-20220225-181056.png
Directory : I:/$Evscope_work/input/observator
File Size : 4.3 MB
File Modification Date/Time : 2022:02:26 06:21:58+01:00
File Access Date/Time : 2022:07:17 16:17:08+02:00
File Creation Date/Time : 2022:03:18 08:34:09+01:00
File Permissions : rw-rw-rw-
File Type : PNG
File Type Extension : png
MIME Type : image/png
Image Width : 2560
Image Height : 1920
Bit Depth : 8
Color Type : RGB
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
Significant Bits : 8 8 8
Image Size : 2560x1920
Megapixels : 4.9

Dans les images sauvées au format png, seulement la date et l’heure (sous Android, car sous iOS, on les perd). et les tags EXIF sont incorporés dans un “chunck” png dédié (eXIf). Ce qui n’est pas un problème… Il suffit de le remplir ! Dans la version 1.6, pas d’infos sur les objets capturés, ni sur la capture. Si on “perd” le nom de fichier, c’est fichu !

Format PNG/V2.0 – Android

Examinons maintenant une “nouvelle” image “Crop” capturée avec la 2.0

ExifTool Version Number : 11.99
File Name : eVscope-20220716-230540.png
Directory : I:/$Evscope_work/VA2
File Size : 3.0 MB
File Modification Date/Time : 2022:07:17 01:05:44+02:00
File Access Date/Time : 2022:07:17 16:14:20+02:00
File Creation Date/Time : 2022:07:17 07:37:16+02:00
File Permissions : rw-rw-rw-
File Type : PNG
File Type Extension : png
MIME Type : image/png
Image Width : 2240
Image Height : 2240
Bit Depth : 8
Color Type : RGB with Alpha
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
>>> Exif Byte Order : Big-endian (Motorola, MM)
>>> Orientation : Unknown (0)
>>> Camera Model Name : eQuinox
>>> GPS Time Stamp : 23:05:00
>>> GPS Altitude Ref : Above Sea Level
>>> GPS Date Stamp : 2022:07:16
>>> GPS Latitude Ref : North
>>> GPS Longitude Ref : East
>>> Software : Unistellar Software v2.0
>>> White Balance : Manual
>>> Gain Control : Unknown (250)
>>> Light Source : Unknown
>>> Exposure Time : 316
>>> Maker Note Unknown Text : (Binary data 123 bytes, use -b option to extract)
>>> User Comment :
>>> Modify Date : 2022:07:16 23:05:00
>>> Make : Unistellar
Significant Bits : 8 8 8 8
Image Size : 2240x2240
Megapixels : 5.0
Shutter Speed : 316
>>> GPS Altitude : 57.6 m Above Sea Level
>>> GPS Date/Time : 2022:07:16 23:05:00Z
>>> GPS Latitude : xx deg xx' x.xx" N
>>> GPS Longitude : x deg xx' xx.xx" E
>>> GPS Position : xx deg xx' x.xx" N, x deg xx' xx.xx" E

Comme l’indique les champs “>>>”, il y a plus de monde dans le “chunck”… Remarquons :
– Exposure time = 316 sec = 5.26 min => ok, correspond
– Shutter speed = 316 => pas ok, car ici, on devrait avoir au environ de 4 sec ! (capture max sur le IMX224 en pose courte, jusqu’à présent)
– GPS Date/Time et info => ok, pour la date et lieu de la capture
– Par contre, il manque des infos clés : le nom de l’objet, les réglages de capture, les coordonnées de l’objet visé, etc… ?
– Mais il y un bloc “propriétaire” à examiner.

V2.0 Décodage du “Maker Note” Exif

Cette zone “Note” est normalement stockée en “lisible”…
Mais on y découvre le contenu suivant :

MC4wOzAuMDswLjA7MC4wOzA1Mjs2OTMxOC42MTI7NDIxMDMzLjgyOzExMjE5OTA5ODgyMTM3My40LTs1Nzg2OTI5MjUyNDMyMy4zNTI7NTI7Mzk1MTk3OzI=

Ceci ressemblant à une Base 64, on décode vite fait…

0.0;0.0;0.0;0.0;052;69318.612;421033.82;112199098821373.4-;57869292524323.352;52;395197;2

Supposition : Le contenu EXIF étant annoncé en “big indian”, on devrait donc garder l’ordre des bytes “tel quel” et en supposant que le “;” est bien un séparateur, on devrait y retrouver des informations de capture… Regardons dans d’autres exemples, y compris acquis sur un autre tube :

Quelques exemples du block “maker note” sur des images “enhanced mode”

Une conclusion à ce stade :
– le type d’image est la dernière valeur ( 1 = Full, 2 = Crop)
– l’avant-dernière valeur est identique pour un objet donné, quelque soit le tube et le temps (coordonnées ou “catalogue” interne ? )
– les 4 premières semblent bien indiquer les réglages

Oui, mais…
Toutes les captures concernées ont été faites en mode “par défaut” au niveau “vision augmentée” de l’APP. Donc par défaut 25 dDB (ou 25.0 dB) de gain
=> On trouve bien “250” comme “gain” annoncé au niveau des champs Exif…
=> Mais si les premiers champs du bloc propriétaire décrivent les conditions de capture, le “052” devrait être inversé 052 => 250 ?

Test : si on prend une image manuellement (donc, une taille “capteur” SANS “vision améliorée”) avec spécifiquement : 27.4 dB et 500ms… (pour améliorer la collimation), on découvre le contenu EXIF suivant :

Camera Model Name : eQuinox
>>> Exposure Time : 0.5
Date/Time Original : 2022:07:18 23:11:06
Brightness Value : 0
Color Space : sRGB
Exif Image Width : 1280
Exif Image Height : 960
White Balance : Auto
GPS Altitude : 57.7669335 m
GPS Date Stamp : 2022:07:18
XMP Toolkit : XMP Core 6.0.0
Maker Note : MC4wOzAuMDswLjA7MC4wOzQ3Mjs5NjQxNy40NDI7Nzc0MjM2LjI0OzY4NTU3OTQ3OTkzMjgxLjkxOzYwNDE5MTY0ODkyNTE5LjMxMjs0Mzs2MjgyMTg7MQ==
User Comment :
Creator Tool : Unistellar Software v2.0
Date Created : 2022:07:18 23:11:06
Title : Arcturus
Image Size : 1280x960
Megapixels : 1.2
>>> Shutter Speed : 0.5

Même avec la même incohérence au niveau “Shutter speed” et “Exposure time”, on retrouve bien 0.5 sec. => ok ! Mais maintenant, il manque désormais des champs EXIF ! (voir premier exemple…)
– White Balance : Manual
– Gain Control : Unknown (250)
– Light Source : Unknown
– Exposure Time : 316
=> Remarque 1 : Les champs les plus intéressants (surtout dans ce mode “manuel”) ont disparu ! Comprenne qui pourra…

On décodant le champ “propriétaire” et obtient :

0.0;0.0;0.0;0.0;472;96417.442;774236.24;68557947993281.91;60419164892519.312;43;628218;1

Et là, comme soupçonné : “472” => “27.4” !
Mwais… Une inversion de type “little > big” indian de type est donc nécessaire
“052” => “052” (II) => “2” “5” “0” => “250” (MM)
“472” => “472” (II) => “2” “7” “4” => “274” (MM)
qu’il faut considérer avec deux décimales fixes.
=> Remarque 2 : pourquoi ne pas avoir mis la bonne valeur de suite, puisqu’on est en Base64 tout de même ?
Décodons le reste… L’objet pointé (Arcturus), à l’heure de la capture (23h11 LT, 18/7/2022), était à

Via “Cartes du Ciel”

Un examen par champ apporte une première hypothèse :

Champ : "96417.442" => "244.071469"  
Par calcul : +245°09'43" , ici : 244,071469° => Az ?

Champ : "774236.24" => "42.632477"
Par calcul : +42°20'22", ici 42,63° => Alt ?

Les autres valeurs : “19.18239974975586”, “0213.91529846191406”, “34”
A ce stade, des suppositions… Pour pouvoir appliquer cette méthode sur tous les champs inventoriés : un brin de code Python (évidemment)…

# -*- coding: utf-8 -*-
"""
Created on Mon Jul 18 18:21:45 2022

Translate Unistellar proprietary Exif data
to usable contents

@author: TTF
"""
def int2bytes(i, enc):
    return i.to_bytes((i.bit_length() + 7) // 8, enc)

def convert_hex(str, enc1, enc2):
    return int2bytes(int.from_bytes(bytes.fromhex(str), enc1), enc2).hex()

def decode_unistellar(orig, debug=False):
    if len(orig) % 2 > 0:
        orig = orig+"0"
    orig_hex = orig.encode("utf-8").hex()
    if debug:
        print("orig = ",orig,"orig hex = ",orig_hex)
        print("converted = ",convert_hex(orig_hex, 'big', 'little'))
    hex_str = convert_hex(orig_hex, 'big', 'little')
    bytes_obj = bytes.fromhex(hex_str)
    ascii_str = bytes_obj.decode('ASCII')
    if debug:    
        print("Converted in ASCII", ascii_str)
    return ascii_str

fields_lines = (("052", "84314,742", "764800,14", "68557947993281,9", "60419164892519,3", "72", "628218"), ("052", "84314,742", "764800,14", "68557947993281,9", "60419164892519,3" ,"72", "628218"), ("052", "31305,612", "448344,82", "908872892238273,4-", "21823689067323,4", "32", "395197"),    ("052", "31305,612", "448344,82", "908872892238273,4-" ,"21823689067323,4", "32", "395197"), ("052", "69318,612", "421033,82", "112199098821373,4-", "57869292524323.352", "52", "395197"), ("052", "64918,652", "580590,33", "325160888008338", "65153537302815,2", "52", "435118"), ("052", "64918,652", "580590,33", "325160888008338", "65153537302815,2", "52", "435118"), ("052", "7109,652", "580590,33", "325160888008338", "65153537302815,2", "82", "435118"), ("052", "9243,022", "499930,27", "432042698992165", "52609878004324,1", "62", "842118"),    ("052", "9243,022", "499930,27", "432042698992165", "52609878004324,1", "62", "842118"), ("052", "54137,633", "589206,83", "60987857207977", "65158740993869,8", "52", "713118"), ("052", "54137,633", "589206,83", "60987857207977", "65158740993869,8", "52", "713118"))

for fl in fields_lines:
    l=''
    for f in fl:
        l = l+ decode_unistellar(f)+","
    print(l+"\n")

Et puis traduisons les champs extraits

Après conversion little <> big

Premières conclusions

A ce stade :

  • La sauvegarde de contenus EXIF est effective, mais “étrange”, car des champs pourtant standards ne sont pas utilisés
  • On n’a pas le “nom de l’objet” visé…. !!!
    (ce qui serait le minimum syndical attendu)
  • Un bloc propriétaire assez exotique peut fournir des informations
    de pointage => une piste pour retrouver l’objet dans Simbad
  • Il y a évidemment une “référence” de l’objet dans un catalogue interne à l’application, on suppose un fichier… Peut-être une piste pour le retrouver plus facilement ?

Comment stocker le nom d’objet dans une image png ?

A voir cela, on se dirait que stocker le nom d’un objet dans une image relève de la prouesse technique… Pourtant, c’est facile… Revenons aux champs réservés du format “png” (en incluant les nouveautés de la version 1.2) :

Critical chunks (must appear in this order, except PLTE
                    is optional):
   
           Name  Multiple  Ordering constraints
                   OK?
   
           IHDR    No      Must be first
           PLTE    No      Before IDAT
           IDAT    Yes     Multiple IDATs must be consecutive
           IEND    No      Must be last
   
   Ancillary chunks (need not appear in this order):
   
           Name  Multiple  Ordering constraints
                   OK?
   
           cHRM    No      Before PLTE and IDAT
           gAMA    No      Before PLTE and IDAT
           iCCP    No      Before PLTE and IDAT
           sBIT    No      Before PLTE and IDAT
           sRGB    No      Before PLTE and IDAT
           bKGD    No      After PLTE; before IDAT
           hIST    No      After PLTE; before IDAT
           tRNS    No      After PLTE; before IDAT
           pHYs    No      Before IDAT
           sPLT    Yes     Before IDAT
           tIME    No      None
           eXIf    No      None
           iTXt    Yes     None
           tEXt    Yes     None
           zTXt    Yes     None

Standard keywords for text chunks:

   Title            Short (one line) title or caption for image
   Author           Name of image's creator
   Description      Description of image (possibly long)
   Copyright        Copyright notice
   Creation Time    Time of original image creation
   Software         Software used to create the image
   Disclaimer       Legal disclaimer
   Warning          Warning of nature of content
   Source           Device used to create the image
   Comment          Miscellaneous comment; conversion from
                    GIF comment

Donc, soit normalement dans les “text chuncks” tel que : iTXt, tEXt, zTXt
ou dans le “semi-standardisé” tag eXIf (avec la considération de l’encodage), c’est très facile d’insérer “Arcturus”…

Faut toujours vérifier…

Par acquis de conscience, regardons si sous iOs (où le nom du fichier image est encore pire…), tout ce qui est analysé ci-dessus reste cohérent…

Format PNG/V2.0 – iOs

Décodage de la capture d’une étoile… (que je retrouve désormais “en tête” des préférées dans le menu, mais je m’interroge bien pourquoi !)

I:/$Evscope_work/VA2_ios/Fawaris_C_TMZL9237.PNG
ExifTool Version Number : 11.99
File Name : Fawaris_C_TMZL9237.PNG
Directory : I:/$Evscope_work/VA2_ios
File Size : 4.1 MB
File Modification Date/Time : 2022:07:15 22:53:16+02:00
File Access Date/Time : 2022:07:18 11:49:28+02:00
File Creation Date/Time : 2022:07:18 11:25:53+02:00
File Permissions : rw-rw-rw-
File Type : PNG
File Type Extension : png
MIME Type : image/png
Image Width : 2240
Image Height : 2240
Bit Depth : 8
Color Type : RGB with Alpha
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
SRGB Rendering : Perceptual
>>> Exif Byte Order : Big-endian (Motorola, MM)
>>> Make : Unistellar
>>> Camera Model Name : eQuinox
>>> Exposure Time : 56
>>> Date/Time Original : 2022:07:15 22:52:57
>>> Brightness Value : 0
Color Space : sRGB
>>> Exif Image Width : 2240
>>> Exif Image Height : 2240
>>> White Balance : Auto
>>> GPS Altitude : xx.xxxxxxx m
>>> GPS Date Stamp : 2022:07:15
>>> XMP Toolkit : XMP Core 6.0.0
>>> Maker Note : MC4wOzAuMDswLjA7MC4wOzA1Mjs1ODY4NzguMjg7NzYwMDY3Ljk1OzkyMjgwMzQ2MjE1MDMxLjU0Ozg1MDg4MTg2NDc1OTMuNjkyOzcyOzk0NzIxODsy
>>>User Comment :
>>> Creator Tool : Unistellar Software v2.0
>>> Date Created : 2022:07:15 22:52:57
>>> Title : Fawaris
>>> Image Size : 2240x2240
>>> Megapixels : 5.0
>>> Shutter Speed : 56
>>> GPS Latitude : xx deg xx' x.xx" N
>>> GPS Longitude : x deg xx' xx.xx" E
>>> GPS Latitude Ref : North
>>> GPS Longitude Ref : East
>>> GPS Position : xx deg xx' x.xx" N, x deg xx' xx.xx" E

ICI, on trouve le nom de l’objet !!!!

Et de plus, la méthode de stockage des métadonnées a visiblement changé, avec l’utilisation du format XMP/RDF (un codage de type XML, dédié aux données dans les images) qui permet l’usage de n’importe quel “schema” de données, même propriétaire

Conclusion : les équipes de développement sous Android et iOS sont visiblement différentes… Et ne se parlent pas trop… 🙁

OK, examinons cela en détail :

62022:07:16  Ĩñµ  iTXtXML:com.adobe.xmp     <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 6.0.0">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:exif="http://ns.adobe.com/exif/1.0/"
            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
            xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:tiff="http://ns.adobe.com/tiff/1.0/">
         <exif:WhiteBalance>0</exif:WhiteBalance>
         <exif:GPSAltitude>150579/2614</exif:GPSAltitude>
         <exif:GPSLatitudeRef>N</exif:GPSLatitudeRef>
         <exif:BrightnessValue>0</exif:BrightnessValue>
         <exif:GPSLatitude>xx,xx.xxxxN</exif:GPSLatitude>
         <exif:GPSLongitudeRef>E</exif:GPSLongitudeRef>
         <exif:ExposureTime>236</exif:ExposureTime>
         <exif:GPSLongitude>x,xx.xxxE</exif:GPSLongitude>
         <exif:MakerNote>MC4wOzAuMDswLjA7MC4wOzA1Mjs1NTAuNzMzOzU5ODQzLjgzOzYwOTg3ODU3MjA3OTc2Ljk2OzY1MTU4NzQwOTkzODY5Ljg0MTs5Mjs3MTMxMTg7MQ==</exif:MakerNote>
         <exif:UserComment/>
         <xmp:CreatorTool>Unistellar Software v2.0</xmp:CreatorTool>
         <photoshop:DateCreated>2022-07-16T23:56:16</photoshop:DateCreated>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">M82 - Cigar Galaxy</rdf:li>
            </rdf:Alt>
         </dc:title>
         <tiff:Model>eQuinox</tiff:Model>
         <tiff:Make>Unistellar</tiff:Make>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

Pas de XSD (schéma) propriétaire avec explication, de la réutilisation de champ pour TIFF, mais cela simplifie… En extrayant les données directement utiles, il suffit de se limiter à

<exif:WhiteBalance>0</exif:WhiteBalance>
         <exif:GPSAltitude>150579/2614</exif:GPSAltitude>
         <exif:GPSLatitudeRef>N</exif:GPSLatitudeRef>
         <exif:BrightnessValue>0</exif:BrightnessValue>
         <exif:GPSLatitude>50,51.1137N</exif:GPSLatitude>
         <exif:GPSLongitudeRef>E</exif:GPSLongitudeRef>
         <exif:ExposureTime>236</exif:ExposureTime>
         <exif:GPSLongitude>4,29.401E</exif:GPSLongitude>
Et surtout :
<dc:title>
     <rdf:Alt>
         <rdf:li xml:lang="x-default">M82 - Cigar Galaxy</rdf:li>
     </rdf:Alt>
</dc:title>

Et immédiatement, via une extraction basique, on trouvera :

0
150579/2614
N
0
50,51.1137N
E
236
4,29.401E
M82 – Cigar Galaxy

Yes ! Ici, on a le nom de l’objet !!!
Pourquoi ne pas avoir fait la même chose du côté Android ???
Si on avait encodé la sauvegarde de manière identique (et complète), il n’y aurait plus de problèmes… Les XMP permettent quasi tout, donc, aucun problème théorique.

De plus, dans les images png sauvées sous iOs:
– on utilise toujours le chunk eXIf (comme sous Android)
et dans celui-ci
– le “bloc” propriétaire est toujours le même
ex : 0.0;0.0;0.0;0.0;052;71530.542;623423.24;892438613259970.91;75587483040358.312;43;628218;2
– on utilise simplement le chunk iTxt pour les données de type XML

En conclusion…

La raison invoquée pour de si profondes modifications entre V1.6 et 2.0, avancée par Unistellar, est de (je cite) : ” Note: cette nouvelle mise à jour est une un nouveau développement qui nous permettra d’implémenter de nouvelles fonctionnalités plus facilement (et plus souvent). Nous vous remercions d’avance de vos soutien et patience dans ce nouveau projet.”

Dont acte… Je vais introduire les remarques dans un ticket pour que les métadonnées évoluent de manière cohérente dans une future version…

La solution technique est simple : au min, rajouter le nom de l’image dans les tags EXIF prévus pour cela (dans les deux versions, voir tableau ci-dessous)

0x010dDocumentNamestringIFD0 
0x010eImageDescriptionstringIFD0
Exif tag : nommer l’image et son usage

Au maximum : généraliser l’usage du XML/XMP dans tous les modes (bref un seul objet et code à maintenir, ce qui serait plus simple…)

Quand aux extensions détectées ici, elles seront progressivement rajoutées dans tous les programmes du site avec la mise à jour vers “2.0” 🙂