Ajout d'une sortie NetCDF

[amiotc]

Explication du problème

A l'heure actuelle, S2P écrit les nuages de points sous la forme de fichier ply. Ces fichiers ne contiennent que les points valides, autrement dit les points dont la position géographique (lat/lon/alt) a pu être déterminée. Ainsi, il est impossible, à partir d'un fichier ply, de retrouver simplement quels points ont généré le point 3D (dans la géométrie capteur de l'image référence et des images secondaires).

Proposition pour corriger le problème

La solution proposée consiste à enregistrer les nuages de points non plus sous la forme d'un fichier ply, mais sous la forme d'un fichier netCDF. Ce type de format permet de stocker plusieurs grilles de types et de tailles différentes. Ainsi la solution propose de définir les grilles suivantes. Sauf mention contraire, les grilles sont dans la géométrie de l'image de référence, c'est-à-dire que leur taille (nb lignes, nb colonnes) correspond à la taille de l'image de référence et que chacune des cellules de la grille correspond à un pixel de l'image de référence (ie, la grille et l'image de référence sont superposables)

• Grille contenant un tuple (longitude, latitude, altitude) des points 3D calculés. Si un tuple n'est pas un type acceptable, construire 3 grilles, une pour chaque valeur
• Une grille par image secondaire contenant un booléen pour indiquer si oui ou non cette vue a participé à l'interpolation des lignes de visée. Le booléen peut être remplacé par les valeurs du pixel de l'image secondaire si ces valeurs sont accessibles.

Conception

En termes de code, nous nous plaçons dans le cas de l'interpolation des lignes de visées : option 'triangulation_mode' positionnée à 'geometric'. Dans cette configuration, le code triangulation.py appelle la fonction multidisp2ply (dans la fonction multidisp_map_to_point_cloud). Il faut donc intervenir au niveau du fichier multidisp2ply.c. Le principe est le suivant : il faut suivre, dans ce fichier, l'écriture des points dans le fichier .ply. En particulier, il existe deux boucles for imbriquées (l'une sur les lignes de l'image de référence, l'autre sur les colonnes). Ces boucles doivent servir à enregistrer toutes les données à écrire dans le fichier netCDF:

• soit en enregistrant les données à la volée,
• soit en les stockant dans une structure adéquate et en écrivant cette structure (qui correspond à une grille du netCDF).

[amiotc]

@AlexandreBerdeaux @astridBourgois @Loicsadou @Boulahbal-Houssem J'ai volontairement laissé la conception un peu vague. Vous avez le nom du fichier dans lequel il faut procéder aux modifications. Ce fichier, en plus d'écrire le .ply, doit également générer le .netCDF. Les parties propres à l'écriture, initialisation du netCDF etc peuvent être développées dans un autre fichier à votre convenance. Si vous avez des questions, n'hésitez pas à laisser des commentaires sur cette issue. Je crois que vous pouvez également, si vous le souhaitez, compléter l'issue si vous trouvez qu'il manque des informations.

[AlexandreBerdeaux]

Petite mise à jour.

Pour enregistrer les données voulue nous sommes arriver à l'organisation de données suivante \:

netcdf data { dimensions: width; //Largeur de la tile length ; //Longueur de la tile views ; // Nombre d'image utilisé variables: double longitude(width, length) ; //Longitude à un pixel de l'image référence double latitude(width, length) ; //Latitude à un pixel de l'image référence double altitude(width, length) ; //Altitude à un pixel de l'image référence int views(width, length, views) ; //La vue views est-elle utilisé lors de la triangulation d'un pixel de l'image de référence?

// global attributes: //Utilisée pour pouvoir ranger les tiles dans l'ordre en vue d'une éventuelle fusion \:row ; //Position en x de la tile dans l'image de référence complète \:column ; //Position en y de la tile dans l'image de référence complète }

Nous étudions encore la possibilité de récupéré les coordonnées de l'image secondaire.

[AlexandreBerdeaux]

Nouvelle mise à jour par rapport à la réunion de ce matin, une verision locale de s2p modifié est disponible sur la branche s2pnetcdf. La structure du fichier netcdf a été changé pour correspondre au format suivant \:

netcdf data { dimensions: width; height; //Longueur de la tile views; variables: double longitude(width, height) ; double latitude(width, height) ; double altitude(width, height) ; int views(width, height, views) ; int slaveimagex(width, height, views) ; //Position x dans l'image secondaire d'un pixel de l'image référence int slaveimagey(width, height, views) ; //Position y dans l'image secondaire d'un pixel de l'image référence

// global attributes: :row = 150 ; :column = 150 ; data: }

[amiotc]

Je ne suis pas sûre de bien comprendre la notation. Pour les derniers éléments, il s'agit de fonctions? Ou bien c'est juste une manière d'écrire?

De manière générale, il faut éviter d'écrire 'x' et 'y' pour indiquer les lignes et les colonnes. Ou bien bien commenter le sens auquel correspond chacune de ces notations. Ici, par exemple, x correspond à la position selon les lignes ou bien en lignes?

[AlexandreBerdeaux]

Pour les derniers éléments c'est deux grilles d'entiers. Pour les x, cela correspond au numéro de colonne, et pour les y au numéro de ligne.

J'ai effectué un renommage des éléments du fichier en espérant que ces derniers soient plus explicites \: netcdf data { dimensions: wh_width = 225 ; wh_height = 225 ; s_sight = 2 ; variables: double longitude(wh_width, wh_height) ; double latitude(wh_width, wh_height) ; double altitude(wh_width, wh_height) ; int selected_sights(wh_width, wh_height, s_sight) ; int width_pos_secondary_image(wh_width, wh_height, s_sight) ; int height_pos_secondary_image(wh_width, wh_height, s_sight) ;

// global attributes: :width_pos_complete_reference = 150 ; :height_pos_complete_reference = 150 ; data: }

[amiotc]

@AlexandreBerdeaux J'ai regardé le code pour le netcdf. Il me semble très bien (je ne l'ai pas encore testé). Est-ce normal que les fichiers inclus netcdf.c et netcdf.h ne soient pas en base? Ces fichiers correspondent-ils bien à ceux qu'on peut trouver sur le github de unidata? Quelle version est utilisée?

[AlexandreBerdeaux]

@amiotc Les fichiers netcdf.h et netcdf.c ne sont pas inclus car ils sont recherché par les paquets de la distribution (via pkg-config --libs libnetcdf-dev). La version utilisée est la 4.1.3 (non disponible sur github).

https://github.com/CS-SI/2018_ups_iarf-rodeco_schoolproject/wiki/Documentation-de-la-sortie-netCDF J'ai cette page pour centraliser les informations à propos de la sortie netCDF et ai déjà ajouté les information d'installation nescessaire.

[jguinet]

@AlexandreBerdeaux, merci pour le code, j'ai visualisé les commits (je n'ai pas encore testé). Le code est de qualité,

il me semble qu'il manque la désallocation de ncfilename dans multidisp2ply.c

char* ncfilename = malloc(strlen(tile_dir)+strlen(FILE_NAME)+1);

[amiotc]

@AlexandreBerdeaux J'ai regardé les commits, et je me demandais lesquels d'entre vous étaient kirapain et llyu. Pure curiosité... Merci

[AlexandreBerdeaux]

@amiotc C'est respectivement le nom du compte Cloud9 d'Astrid, que j'emprunte pour develloper depuis l'université, et le nom de compte de mon ordinateur personnel.