Structure interne des fichiers de suivi
Les fichiers de suivi Eros contiennent les résultats des analsyes des images dans un format binaire propre à l'expérience.
Assez peu de documents existent sur la description du format interne de ces fichiers. Les notes qui suivent viennent des quelques documents de description, plutôt orientés vers l'utilisation d'une bibliothèque, de l'analyse de codes C découverts, et de pas mal d'expérimentation pour tenter de valider différentes hypothèses.
Des applications ont été développées en ce sens, décrites à la page des outils liés aux suivis.
La conversion des suivis en Json n'est qu'un aspect de la préservation des données de l'expérience, plus largement étudié dans la page sur les formats ouverts.
Structure générale
Un fichier de suivi est constitué d'une suite d'enregistrements matérialisés par des structures C. Ces structures sont écrites directement dans le fichier grâce à l'instruction fwrite().
Le fichier débute par un entête indiquant le nombre d'images analysées et le nombre d'étoiles détectées sur ces images, l'organisation des mots machines (little ou big endian), le numéro de version du format, une marque de validité et la taille des différents enregistrement.
Cet entête est suivi par la liste des signatures des enregistrements sous la forme d'une suite de lettres représentant le type des attributs des structures C.
La structure correspondant aux mesures réalisées pour une étoile sur une image, par exemple, débute par:
int numEt
int xRef
float flxMean
float flxSig
float fluxRef
float xPos
float yPos
Le début de la chaîne de caractères représentant sa signature
est donc: IIFFFFF...
Ici, les entiers sont composés de 4 octets, tout comme
les réels simples précisions, ou float. La lettre S est
destinée aux entiers courts, signés ou non (short int ou
unsigned short int) et la lettre D représente les réels
double précision, ou double, sur 8 octets.
La représentation d'un tableau se fait simplement en indiquant
autant de fois que nécessaire le type de base. Un exemple
d'un tel tableau est la liste des voisins d'une étoile:
unsigned short int voisins[8] qui est matérialisée par
la séquence SSSSSSSS.
Le bloc des signatures est suivi d'une troisième zone, de dimension libre, permettant d'enregistrer une suite de lignes de commentaires. Pour les différents fichiers étudiés, ce bloc de commentaires décrit les noms des attributs des différentes structures présentes dans le suivi.
DumpSuivi donne accès au bloc des signatures et au bloc des commentaires:
% DumpSuivi lm01000krp501.sv -header
#Suivi Parameters
Name Programme Champ Camera Ccd Filtre Production Bloc Type Nametype Byteorder
------------- --------- ----- ------ --- ------ ---------- ---- ------ -------- -------------
lm01000krp501 lm 010 0 0 r p5 1 EROS_2 EROS_2 LITTLE_ENDIAN
#Header
Total Size Header Size Nb Stars Nb Mesures Mesures/Block Type Cor Marker SwapFlag
---------- ----------- -------- ---------- ------------- ---- ---------- --------
139662445 217 32768 134 10 10 134 0xFFFF
#Record Signatures
Record Signature
------------ -----------------------------------------------------------------------------------------------
SvGlobalInfo IIIIIIIFFFFFDDDDDDDDDDDDDDDDDDDDDDDDDDDDI
SvStarInfo IIFFFFFFFFSSSSSSSSSS
SvTimeInfo IIIIIFFFFFFFFFFFFFDDDDDDDDDDDDDDDDDDDDDDDDDDDDIFFIFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFSSSSISSFF
SvMesure FFSSSSSSSSSSS
#Comments
Comments
--------------------------------------------------------------------------
Fichier de suivi Type 10 (CCD EROS/ MARLY)
GlobInfo : NumCCD Couleur NumChamp IRes[4] AlphaHr DeltaDg GainCCD FRes[2]
StarInfo : NumEt XRef FlxMean FlxSig FLuxRef XPos YPos
. FgRef NbVois Voisin[8] DisMin DisM2 DisM2R
TimeInfo : NumPhoto TStart Expose NbOkPS NbOKGF Fond SigFond
. SigX SigY Rho SgX SgY PxSiz[2] CrVal[2] DelX DelY
.. PolxyRC[3][2] PolxyCR[3][2] LargX[2] LargY[2] MidX[2] MidY[2]
... XMin[2] XMax[2] YMin[2] YMax[2] DegPolTG Absorption AirMass
.... FgCalib Calib[8] Resol[3][6] PFitErr[2][5]
..... PSF1D PSF2D Version Revision DateHeure TSid ObsId FRes[2]
Mesure : Flux Xi2 ErrFlux Fond Flx0 Fnd0 Xi20
. S9Pix PixMax X Y SigX SigY
La quatrième zone est une structure nommée GlobalInfo présentant les paramètres du quart de CCD analysé. Malheureusement, ces informations qui pourraient être particulièrement utiles ne semblent pas être pertinentes et semblent être toujours nulles ou à 1.
La cinquième zone est une suite de descripteur d'étoiles de type StarInfo. Il y a un descripteur par étoile. Le nombre d'étoiles suivies est indiqué dans l'entête du fichier. La structure StarInfo débute par le numéro de l'étoile. Ce numéro semble correspondre à la position du descripteur dans la liste en convention Fortran, c'est-à-dire que l'étoile à la 5° position porte le numéro 5. C'est ce numéro d'étoile qui est utilisé comme identifiant dans les courbes de lumière.
Attention: dans le cas d'une lecture en C, en Java, ou autre, l'index du descripteur dans la liste, débutant à 0, correspond donc au numéro de l'étoile - 1.
La valeur -1 semble être utilisée pour indiquer que l'étoile
n'est pas analysée.
Remarque: la liste des descripteurs d'étoiles provient du fichier des références. Elle est immuable pour les différents blocs d'un même quart de CCD pour une même couleur. Ce point est important car une étoile porte le même identifiant dans tous les blocs de la même couleur.
Mais les numéros d'identification des étoiles ne sont pas nécessairement les mêmes en bleu et en rouge, même s'ils le sont souvent. Pour palier cette difficulté une seconde information est enregistrée qui donne le numéro d'identification de l'étoile dans le bloc de l'autre couleur.
Il semble que la convention veuille que le numéro d'étoile utilisé dans les courbes de lumière soit le numéro rouge.
Les vraies difficultés débutent avec la sixième zone ! Celle-ci est constituée de deux blocs: une suite de description des images analysées, nommée TimeInfo, et une suite de mesures réalisées pour les étoiles sur les images, nommée Mesure.
Comme le nombre d'images n'est pas connu à priori, ces informations sont ajoutées au fur et à mesure des analyses. MAIS, dans un souci d'efficacité des IOs, les descripteurs d'images et les mesures sont groupés. Ainsi, la sixième zone débute par une suite de descripteurs d'images dont le nombre est indiqué dans l'entête sous l'appelation Mesures par Block. Elle se poursuit par une suite de listes de mesures, à raison d'une liste par étoile, contenant les mesures réalisées sur chacune des images décrites dans le bloc. Si donc le facteur de blocage est 10 et que le nombre d'étoiles est de 32768, le bloc des mesures contiendra 32768 vecteurs de 10 mesures.
Cette zone est préallouée à la première utilisation et est remplie au fur et à mesure des analyses jusqu'à ce que toutes les structures préallouées soient remplies et qu'il faille allouer une nouvelle zone. De ce fait, si le nombre d'images analysées n'est pas un multiple du facteur de blocage, la dernière zone TimeInfo/Mesure se termine par des structure non remplies, qu'il convient d'ignorer.
Le diagramme suivant résume cette organisation, en supposant le facteur de blocage égale à 10:
Entête
Signatures[1..4]
Comments[]
StarInfos[1..nbStars]
TimeInfo[1..blockSize]
StarInfos[1..nbStars][1..blockSize]
TimeInfo[11..2xblockSize]
StarInfos[1..nbStars][11..2xblockSize]
...
Attention: Seules 4 signatures sont enregistrées, correspondant respectivement aux structures GlobalInfo, StarInfo, TimeInfo et Mesure. La signature "0", correspondant aux commentaires, n'existe pas, le bloc de commentaires étant une suite de chaînes de caractères sans structure propre.
En détaillant l'organisation de la zone TimeInfo/Mesure:
time{img1} time{img2} .. time{img10}
mesure{star1, img1} mesure{star1, img2} .. mesure{star1, img10}
mesure{star2, img1} mesure{star2, img2} .. mesure{star2, img10}
...
mesure{starMax, img1} mesure{starMax, img2} .. mesure{starMax, img10}
time{img11} time{img12} .. time{img20}
mesure{star1, img11} mesure{star1, img12} .. mesure{star1, img20}
mesure{star2, img11} mesure{star2, img12} .. mesure{star2, img20}
...
mesure{starMax, img11} mesure{starMax, img12} .. mesure{starMax, img20}
...
time{img131} time{img132} time{img133} time{img134} <vide:135> .. <vide:140>
mesure{s1, img131} mesure{s1, img132} mesure{s1, img132} mesure{s1, img134} <vide:s1,i135> ...<vide:s1,i140>
mesure{s2, img131} mesure{s2, img132} mesure{s2, img132} mesure{s2, img134} <vide:s2,i135> ...<vide:s2,i140>
...
mesure{sX, img131} mesure{sX, img132} mesure{sX, img132} mesure{sMax, img134} <vide:sX,i135> ...<vide:sX,i140>
Restrictions
Plusieurs points ayant posés problèmes méritent d'être soulignés quant à l'organisation des données dans les fichiers de suivi.
Auto-documentation du format
Le mécanisme d'auto-documentation du format du suivi est certe une bonne initiative, mais malheureusement, des évolutions, sans doute tardives, n'ont pas été reportées dans les signatures ni la description des structures présentées en commentaires. On ne peut donc pas se fier entièrement à ce mécanisme.
Cette difficulté semble concernée essentiellement la structure TimeInfo.
Sa signature se termine par ISSFF et les derniers attributs de
sa description dans le bloc Commentaires sont DateHeure TSid ObsId FRes[2]
- ce qui est cohérent. Mais malheureusement incorrect si on en croit
la lecture du code où le dernier tableau de 2 floats est remplacé
par un entier, DTU, et un seul float FRes. La signification de FRes
est toujours inconnue mais DTU semble correspondre à une date en
temps universel. Ce champ n'est cependant pas renseigné dans les
premières versions utilisées dans les expérimentations.
Ceci étant, cette ambiguïté ne change pas la taille de la structure
- le miracle des accès directs en mémoire du langage C.
Octets fantômes
Les machines "modernes" sont sensibles à l'organisation des données en mémoire et imposent des alignements sur des frontières paires. Pour optimiser les performances des accès mémoires, les compilateurs alignent les structures de données de manière à respecter ces exigeances. Lorsque les attributs de la structure ne respectent pas les contraintes d'alignement, les compilateurs intercallent des octets ‟fantômes” entre les variables mal alignées.
C'est le cas de la structure d'entête, Header, où deux octets fantômes
sont intercallés entre l'indicateur du type du suivi, uint_2 Type,
et le marqueur de (non)corruption int_4 FgCorrupt.
Ces deux octets ne posent pas de problèmes aux programmes écrits en C utilisant la lecture directe du fichier grâce à fread(). A l'inverse, pour les langages n'autorisant pas les transferts directs en mémoire, comme Java, une lecture mot à mot est la seule alternative et ces octets fantômes doivent être pris en considération.
Octets d'ajustement
Le même problème d'alignement des structures mémoires sur des frontières paires se présente lorsque la taille des structures n'est pas un multiple du type de plus grande taille présent dans la structure. Pour garantir un alignement correct, le compilateur ajoute des octets d'ajustement (padding) qu'il place à la fin.
Deux structures sont concernées par ce phénomène: GlobalInfo, où 4 octets sont ajoutés, et Mesure, qui compte 2 octets supplémentaires.
Mais comme à l'époque où l'analyse des images a été réalisée l'espace disque, et bande, était précieux, la bibliothèque d'enregistrement recalle la position courante dans le fichier après chaque écriture de manière à "gomer" ces octets intempestifs !
4 octets perdus dans GlobalInfo pourrait être sans importance, mais 2 octets en plus dans la structure Mesure multipliés par 32768 étoiles mulipliés par 134 images analysées représente de l'ordre de 8 Mo - un trésor dans les années 90...
Cette accrobatie est sans importance pour les langages imposant une lecture mot à mot des données, mais elle doit être prise en compte en cas de lecture directe, typiquement C, où la position courante doit être recalculée et ajustée à chaque lecture.
Organisation des mots-machines
Les premières versions des suivis ne semblaient pas tenir compte de l'ordre des octets dans les mots-machines - heureux temps où une seule plateforme régnait en maître :-). La situation semble avoir changée, peut-être après le passage à UNIX et à des architectures de machines plus hétérogènes.
Toujours est-il que l'entête du suivi contient un marqueur en liaison
avec l'organisation des mots-machines, uint_2 Swap, mais il est placé
très loin dans la structure et son interprétation n'est pas très claire.
Il semble que si sa valeur est "-1" (0xFFFF),
le fichier a été écrit dans l'ordre naturel de la machine.
Mais il ne semble pas y avoir d'information sur quel était cet ordre.
Toujours est-il que tous les suivis étudiés sont de type little endian. Pas de chance, Java utilise l'organisation "réseau", c'est-à-dire big endian. Une inversion des octets avant leur conversion en mots est donc nécessaire. Ceci étant, les performances des implémentations récentes de la machine virtuelle Java rendent le surcoût de cette inversion négligeable face à la nécessité de lire les données sous la forme de blocs d'octets et de reconstituer ensuite les valeurs.
Toutefois, pour éviter des confusions d'interprétation, la détection de l'organisation du suivi ne s'appuie pas sur le marqueur de swap mais sur la taille du fichier, qui se trouve aussi être le premier mot de ce fichier. La logique est simple: si, en Java, la conversion en un entier des 4 premiers octets donne la taille du fichier, le fichier est considéré comme codé Big Endian. Si à l'inverse, la conversion en un entier en croisant les octets donne la taille du fichier, celui-ci est déclaré Little Endian, et hélas doit être swappé au vol. Et si rien ne marche, le fichier est déclaré corrompu et la lecture s'arrête. L'avantage de cette approche est qu'elle peut être réalisée sur les 4 premiers octets du fichier.
Indicateurs de validité
L'entête du suivi contient un attribut indiquant si le suivi est valide ou non. Par convention, sa valeur doit être égale au nombre d'images analysées.
Par ailleurs, l'entête du suivi débute par la taille en octets du fichier. Si cette condition n'est pas respectée, le fichier a certainement été tronqué et ne doit pas être utilisé.
Codage des dates
Le codage des temps est toujours quelque chose de compliqué dans Eros. Dans le cas des suivis, trois mécanismes sont utilisés: un codage simple sous la forme d'un nombre de secondes, un codage en deux parties constituées d'un nombre de jours et d'un instant dans la journée, et une variante de la seconde forme réduite à un instant dans la journée, essentiellement destinée à la représentation de l'heure sidérale.
Le codage sous la forme d'un nombre de secondes est utilisé pour la date d'observation. Mais comme l'espace mémoire est précieux, l'origine des temps est pris au 1er Janvier 1990, à 0H alors que l'origine traditionnelle sous UNIX est le 1 Janvier 1970. Ce décalage permet de réduire suffisamment le nombre de secondes pour coder une date entre 1995 et 2005 sur un entier de 4 octets.
Le codage en termes de jours et d'instant dans la journée est utilisé pour une autre représentation de la date d'observation et pour la conversion en temps universel de cette date. Ce codage met en action deux octets courts non signés codés sur un même entier de 4 octets. Il faut donc décoder les deux champs via des masques binaires. Par convention, si l'entier de 4 octets est égal à -0x7FFFFFFF ou à 0x7FFFFFFF la date est considérée comme invalide ou non renseignée. Le défaut de ce codage est que les 86 400 secondes d'une journée sont incompatibles avec les 65 535 valeurs pouvant être codées sur un entier court, même non signé, de 2 octets. L'instant dans la journée est donc divisé par 2. Pour retrouver l'heure d'observation, il faut donc multiplié la valeur du second mot par 2. Ce qui limite la précision du codage à 2 secondes.
Le codage de l'instant dans la journée sur un entier court non signé souffre de la même limitation. Ce codage est utilisé pour la représentation de l'heure sidérale.
Identification des images
Les images Eros 2 portent des noms certes très explicites mais un peu longs. Il n'était donc pas possible de les conserver dans les suivis. Sans compter qu'une partie du nom est immuable, ne dépend que du quart de CCD traité, et peut donc parfaitement être reconstruit. L'identification de l'image est donc réduite à la date de la nuit d'observation et son numéro d'ordre dans la nuit.
La date de l'image (voir Nomenclature) est codée sur 4 caractères. Le numéro de prise de vue peut atteindre théoriquement 3 caractères (il est limité à 999). Pour réduire la place nécessaire à 4 octets, et rester compatible avec Eros 1, un codage assez complexe est mis en place.
- Le code de la caméra (0 ou 1) est multiplié par 100 millions.
- Puis l'année, comptée depuis 1990, est multipliée par 10 millions.
- Le mois, de 1 à 12, est multiplié par 100 milles.
- Le jour par mille.
- Et enfin l'ordre de prise de vue est ajouté au tout.
Pour différencier les images Eros 1 des images Eros 2, le code des caméras Eros 2 est décalé de 10, soit 10 pour la caméra 0 et 11 pour la caméra 1.
Soit
= camera {1,2} * 100 000 000 // Eros 2: camera {10,11}
+ annee {0, 9} * 10 000 000
+ mois {1, 12} * 100 000
+ jours {1,31} * 1 000
+ ordre {0,000}
Ce codage aurait pu marcher si ce n'est que la fonction de codage travaille directement sur le nom de l'image et convertie l'année, exprimée comme un caractère, en un entier (atoi()). Cela ne pose pas de problème pour Eros 1, dont les campagnes d'observation vont de 1991 à 1995, et donc le code de l'année dans le nom va de '1' à '5'. Mais cela ne marche pas pour Eros 2 qui a pris des données après 2000, et donc avec des codes années 'a', 'b', ...
Pour reconstruire la référence de l'image il faut donc s'appuyer sur les paramètre du nom du suivi et sur le décodage du numéro photo indiqué dans TimeInfo en ignorant l'année.
Association d'étoiles/Etoiles associées
La détection des étoiles a été effectuée grâce à une image de bonne qualité, typiquement une image créée explicitement pour cette usage à partir de plusieurs autres bonnes images. Pour des raisons d'efficacité, le processus était réalisé séparément pour les images rouges et les images bleues. Une ultime étape consistait à associer les étoiles bleues et les étoiles rouges afin de pouvoir les analyser dans les deux couleurs.
Dans les suivis, ce processus se matérialise par des listes d'étoiles différentes en rouge et en bleue, et donc des numéros différents pour les étoiles rouges et les étoiles bleues. L'association de l'étoile avec son congénère de l'autre bloc se fait couplant son numéro avec le numéro de l'étoile de l'autre bloc. Cette seconde valeur est supportée par un attribut xRef dans le descripteur des étoiles.
Une étoile est donc considérée comme effectivement associée si le couple [numéro rouge, référence bleue] du bloc rouge est conforme au couple [numéro bleu, référence rouge] du bloc bleu.
Ce point est important car il semble que seules les étoiles correctement associées aient été retenues pour la création des courbes de lumière - même si ce seul critère n'ait pas suffit: il existe beaucoup d'étoiles associées dans les suivis étudiés pour lesquelles il n'existe pas de courbes de lumière.
Il semble que par convention la préférence soit donnée à la couleur rouge et c'est l'identifiant de l'étoile dans cette couleur qui est retenu pour nommer les courbes de lumière.
Doublons
Une image peut apparaitre plusieurs fois dans un fichier de suivi. Cette situation résulte d'un retraitement de l'image. A priori, les dernières analyses sont considérées comme valides, et par conséquent, les précédents sont ignorés. En effet, si ce n'était pas le cas, un nouveau traitement aurait été programmé pour corriger le traitement incorrect.
Description des structures
La description des structures d'un suivi est principalement issue des fichiers de définition (fichier h) de la librairie C Peida. Les octets fantômes et les octets de remplissage sont également indiqués. Si les octets fantômes peuvent être ignorés en cas de lecture directe, ils doivent être pris en compte pour une lecture mot à mot. Et à l'inverse, les octets de remplissage, absent du fichier, peuvent être ignorés dans le cas d'une lecture mot à mot mais doivent être pris en compte si la lecture se fait en mode direct. C'est pourquoi la taille effectivement utilisée dans le suivi des différentes structures est également indiquée, de même que les signatures des structures telles qu'elles apparaissent dans le fichier. On verra que dans un cas, la signature de la structure est incorrecte.
Les noms des attributs sont ceux utilisés en Java, qui se retrouvent donc dans les transcriptions Json.
La description des attributs est indiquée lorsqu'elle est connue.
Les conventions de typage sont celles du langage C. Dans le cas de Java, le format le plus proche est utilisé. Dans le cas de Json, le question ne se pose pas.
| Type | Usage | Nombre d'octets | Java |
|---|---|---|---|
| int_4 | entier signé standard | 4 | int |
| int_2 | entier signé court | 2 | short |
| uint_2 | entier non signé court | 2 | short |
| float | réel simple - 4 octets | 4 | float |
| double | réel double précision | 8 | double |
Header
- Nom Java/Json: SvHeader
- Somme des attributs: 46
- Taille effective: 48
- 2 octets fantômes d'ajustement au sein de la structure
| Attribut | Type | Octets | Description | Notes |
|---|---|---|---|---|
| totalSize | int_4 | 4 | Taille totale du fichier en octets | |
| headerSize | int_4 | 4 | Taille de l'entête en octets | 1 |
| recordSizes[5] | uint_2 | 5x2 | Taille des structures | 2 |
| mesuresPerBlock | uint_2 | 2 | Facteur de blocage: Mesures/Bloc | 3 |
| nbStars | int_4 | 4 | Nombre total d'étoiles | |
| nbMesures | int_4 | 4 | Nombre total de mesures | 4 |
| formatsLength[5] | uint_2 | 5x2 | Longueur des formats | 5+2 |
| swapFlag | uint_2 | 2 | Indicateur de swapping | 6 |
| type | uint_2 | 2 | Type de suivi | 7 |
| fantôme | 2 | octets d'alignement | 8 | |
| corruptionMarker | int_4 | 4 | Marque de validité du fichier | 9 |
Note 1 La taille de l'entête inclue le bloc des signatures. Attention: la taille apparente de l'entête, si on ajoute simplement la taille de chacun des attributs est de 46. Le compilateur ajoute 2 octets d'ajustement avant corruptionMarker pour d'aligner cet attribut sur une frontière de 4 octets, puisque c'est un entier de 4 octets. La somme des signatures pour un fichier de type 10 est de 169 caractères. La valeur headerSize est donc de 48 + 169 = 217.
Note 2 Ces 5 entiers donnent les tailles effectivement utilisées dans le fichier des différentes structures. Ces valeurs permettent lors d'une lecture directe des enregistrements de calculer l'index effective du début de chaque bloc afin de redéfinir la position du pointeur de lecture dans le fichier.
Les cinq éléments du tableau correspondent aux structures suivante:
- 0: Comments - le bloc de commentaires ne correspondant pas à une structure C, cette information donne directement la taille du bloc de commentaires.
- 1: Global Info
- 2: Star Info
- 3: Time Info x mesures par bloc
- 4: Mesure x mesures par bloc
ATTENTION ! Les tailles indiquées pour les structures Time Info et Mesure sont multipliées par le facteur de blocage. Ainsi, pour un suivi standard avec le facteur de blocage par défaut (mesuresPerBlock) de 10, la taille de la structure TimeInfo, égale à 480, étant multipliée par 10, la valeur 4800 apparait dans recordSizes[3]. La même opération est réalisée pour recordSizes[4] qui contient 300, soit la taille de Mesure, égale à 30, multiplié par 10, le facteur de blocage.
Note 3 Ce facteur, dit facteur de blocage, indique combien de descripteur d'images sont enregistrés à la suite dans chaque zone Times/Mesures, et donc la taille des vecteurs de mesures pour chacune des étoiles suivies enregistrés après les descripteurs d'image.
Note 4 Le terme mesure est à prendre ici dans le sens d'images analysées; cette valeur représente donc le nombre d'images traitées.
Note 5 Ces 5 entiers donnent la longueur des chaînes de caractères décrivant les types des attributs des différentes structures. Les éléments du tableau correspondent aux définitions présentées dans la Note 2 à l'exception notable du premier élément, associé au bloc des commentaires, qui n'étant pas associé à une structure n'a pas de signature - la valeur du premier élément est donc toujours 0.
Note 6 On l'a vue, l'interprétation de cette valeur est peu clair.
Note 7 Tous les suivis étudiés ont le code 10.
Note 8 Deux octets fantômes sont placés par le compilateur de manière à aligner la position de l'attribut suivant, qui est un entier de 4 octets.
Note 9 Le fichier est considéré comme valide si cet attribut est égal au nombre d'images traitées, soit l'attribut nbMesures.
Signatures
Les signatures sont considérées comme faisant partie de l'entête. Elles débutent après la partie fixe de l'entête sous la forme d'un bloc de caractères dont la taille est déterminée est soustrayant à la valeur de l'entête, indiquée par l'attribut headerSize, sa taille effective, soit 48 octets (le sizeof de la structure, intégrant les 2 octets d'ajustement). Cette zone représente donc, pour un suivi standard, 169 caractères.
Les signatures sont écrites sans séparateur. Il faut donc utiliser l'information enregistrée dans le tableau formatsLength pour connaitre la taille de chaque signature. Le bloc de commentaires n'étant pas associé à une structure n'a pas de signature. La valeur d'un premier élément, formatsLength[0] est égale à 0.
Comments
Le bloc de commentaires débute après le bloc de signatures, c'est-à-dire à la fin de l'entête, dont la taille est donnée par l'attribut headerSize. Le bloc de commentaires débute donc à cette position. Contrairement aux signatures, il s'agit d'une suite variable de chaînes de caractères dans la convention C, c'est-à-dire terminée par un octet 0. A l'usage, on s'aperçoit même qu'il peut y avoir de nombreux 0 les uns à la suite des autres...
La taille de cette zone, c'est-à-dire le nombre total de caractères constituant le bloc de commentaires, y compris les 0 de fin de chaînes, est donnée par l'attribut recordSizes[0].
Empiriquement, les chaînes de caractères de cette zone sont toujours les mêmes dans tous les suivis étudiés.
Global Info
- Nom Java/Json: SvGlobalInfo
- Taille effective: 280
- Somme des attributs: 276 - c'est la valeur dans recordSizes[1].
- 4 octets d'ajustement de la taille de la structure sont ajoutés par le compilateur à la fin.
| Attribut | Type | Octets | Description | Signature | Notes |
|---|---|---|---|---|---|
| numCCD | int_4 | 4 | numéro du CCC | I | 10 |
| couleur | int_4 | 4 | code filtre ? | I | 10 |
| numChamp | int_4 | 4 | code du champ | I | 10 |
| iRes[4] | int_4 | 4x4 | IIII | ||
| alphaHr | float | 4 | F | ||
| deltaDg | float | 4 | F | ||
| gainCCD | float | 4 | F | ||
| fRes[2] | float | 4x2 | FF | ||
| polxyBR[3][2] | double | 8x3x2 | DDDDDD | ||
| polxyRB[3][2] | double | 8x3x2 | DDDDDD | ||
| largX[2] | double | 8x2 | DD | ||
| largY[2] | double | 8x2 | DD | ||
| midX[2] | double | 8x2 | DD | ||
| midY[2] | double | 8x2 | DD | ||
| xMin[2] | double | 8x2 | DD | ||
| xMax[2] | double | 8x2 | DD | ||
| yMin[2] | double | 8x2 | DD | ||
| yMax[2] | double | 8x2 | DD | ||
| degPolTG | int_4 | 4 | I | ||
| padding | 8 | ajustement |
Note 10 Ces attributs sont hélas toujours à 0.
Star Info
- Nom Java/Json: SvStarInfo
- Somme des attributs: 60
- Taille déclarée: 60 - c'est la valeur dans recordSizes[2].
| Attribut | Type | Octets | Description | Signature | Notes |
|---|---|---|---|---|---|
| numEt | int_4 | 4 | numéro de l'étoile | I | 11 |
| xRef | int_4 | 4 | numéro étoile associée | I | 12 |
| flxMean | float | 4 | F | ||
| flxSig | float | 4 | F | ||
| fluxRef | float | 4 | F | ||
| xPos | float | 4 | F | ||
| yPos | float | 4 | F | ||
| disMin | float | 4 | F | ||
| disM2 | float | 4 | F | ||
| disM2R | float | 4 | F | ||
| fgRef | uint_2 | 2 | S | ||
| nbVoisins | uint_2 | 2 | S | ||
| Voisins[8] | uint_2 | 2x8 | SSSSSSSS |
Note 11 La valeur -1 semble signifiée que l'étoile est rejetée. Toutefois, l'incrémentation des numéros d'étoiles tient compte de cette étoile. Ainsi, si l'étoile précédente portait le numéro 105, l'étoile suivante portera le numéro 107.
Note 12 L'attribut xRef donne le numéro de l'étoile associée dans l'autre couleur. Lorsque le numéro de l'étoile est -1, la valeur xRef est fixée à 0. Mais le code 0 semble aussi signifier que l'étoile n'est pas associée, puisque des étoiles avec un numéro valide ont pour xRef le code 0.
Time Info
- Nom Java/Json: SvTimeInfo
- Somme des attributs: 480
- Taille déclarée: 480 x mesures par bloc - typiquement 480 x 10 = 4800
| Attribut | Type | Octets | Description | Signature | Notes |
|---|---|---|---|---|---|
| numPhoto | int_4 | 4 | Codage de l'image | I | 13 |
| tstart | int_4 | 4 | Date d'observation | I | 14 |
| expose | int_4 | 4 | Durée d'exposition | I | 15 |
| nbOkPS | int_4 | 4 | I | ||
| nbOkGF | int_4 | 4 | I | ||
| fond | float | 4 | F | ||
| sigFond | float | 4 | F | ||
| sigX | float | 4 | F | ||
| sigY | float | 4 | F | ||
| rho | float | 4 | F | ||
| sgX | float | 4 | F | ||
| sgY | float | 4 | F | ||
| pxSiz[2] | float | 4x2 | FF | ||
| crVal[2] | float | 4x2 | FF | ||
| delX | float | 4 | F | ||
| delY | float | 4 | F | ||
| polxyRC[3][2] | double | 8x3x2 | DDDDDD | ||
| polxyCR[3][2] | double | 8x3x2 | DDDDDD | ||
| largX[2] | double | 8x2 | DD | ||
| largY[2] | double | 8x2 | DD | ||
| midX[2] | double | 8x2 | DD | ||
| midY[2] | double | 8x2 | DD | ||
| xMin[2] | double | 8x2 | DD | ||
| xMax[2] | double | 8x2 | DD | ||
| yMin[2] | double | 8x2 | DD | ||
| yMax[2] | double | 8x2 | DD | ||
| degPolTG | int_4 | 4 | I | ||
| absorption | float | 4 | F | ||
| airMass | float | 4 | F | ||
| fgCalib | int_4 | 4 | I | ||
| calib[8] | float | 4x8 | FFFFFFFF | ||
| resol[3][6] | float | 4x3x6 | FFFFFFFFFFFFFFFFFF | ||
| pFitErr[2][5] | float | 4x2x5 | FFFFFFFFFF | ||
| psf1D | uint_2 | 2 | S | ||
| psf2D | uint_2 | 2 | S | ||
| version | uint_2 | 2 | F | ||
| revision | uint_2 | 2 | F | ||
| dateHeure | int_4 | 4 | Date d'observation | I | 16 |
| tSid | uint_2 | 2 | Heure d'observation | S | 16 |
| obsId | uint_2 | 2 | Code observatoire | S | 17 |
| dtu | int_4 | 4 | Date universelle | F | 18+16 |
| fRes | float | 4 | F |
Note 13 L'encodage de l'image ne fonctionne que pour les années 1990-1999 (voir Identification des images).
Note 14 La date d'observation est exprimée comme un nombre de secondes compté à partir du 1er Janvier 1990 à 0 heure.
Note 15 La durée d'exposition en secondes issue de l'entête FITS de l'image analysée.
Note 16 Les dates et heures locales et en temps universel sont codées comme deux entiers courts non signés donnant l'un le nombre de jours depuis le 1er Janvier 1990 et l'autre le nombre de secondes dans la journée divisée par deux (voir Codage des dates).
L'heure sidérale est codée comme un entier court non signé divisé par deux (même remarque).
Note 17 L'observatoire est identifié par un entier, la valeur 1 étant attribué au Marly. Il ne semble pas que d'autres codes soient utilisés.
Note 18 L'attribut dtu, donnant la date d'observation en temps universel est utilisé comme un entier mais est déclaré comme un réel simple. Cela ne change pas la taille de l'enregistrement.
Time Info Eros 1
La structure Time Info pour les suivis Eros 1 est similaire
à ceux d'Eros 2 présenté ici à l'exception des attributs tSid
et obsId qui n'existent pas et sont remplacés par un réel simple.
La fin de la signature dans ce cas est FFF et non SSFF.
Mesure
- Nom Java/Json: SvMesure
- Taille effective: 32
- Somme des attributs: 30 x mesures par bloc - typiquement 30 x 10 = 300
- 2 octets d'ajustement sont ajoutés à la fin de la structure
| Attribut | Type | Octets | Description | Signature | Notes |
|---|---|---|---|---|---|
| flux | float | 4 | F | ||
| xi2 | float | 4 | F | ||
| errFlux | int_2 | 2 | S | ||
| fond | int_2 | 2 | S | ||
| flx0 | int_2 | 2 | S | ||
| fnd0 | int_2 | 2 | S | ||
| xi20 | int_2 | 2 | S | ||
| s9Pix | int_2 | 2 | S | ||
| pixMax | int_2 | 2 | S | ||
| x | uint_2 | 2 | S | ||
| y | uint_2 | 2 | S | ||
| sigX | uint_2 | 2 | S | ||
| sigY | uint_2 | 2 | S |