Proposition de feuille de route pour le projet CNAM "Aladin Sky Browser" (hops je le baptise)
suite à la discussion de ce matin (Anaïs, François et Pierre)

1) Test du code Healpix pour pouvoir découper la sphère céleste dans un système qui évitera les "effets de bords de plaque". Il faudra voir comment greffer sur ce code un système de fichiers et/ou de BD pour stocker les valeurs des pixels. Le test se fera sur 4 images ACS bord à bord. François B. Détermine s'il vaut mieux utiliser Healpix ou HTM. Garder à l'esprit que le code doit obligatoirement exister en java (en tout cas pour la partie cliente).

2) Repartir du code Aladin java pour intégrer la partie cliente. Le plus efficace sera certainement de surcharger la classe ViewSimple. Elle concerne tout ce qui fait le chargement, l'affichage et la gestion d'évènements d'un "panel" Aladin. Il faudra également voir les interactions avec la classe ZoomView qui gère la représentation de la portion visible de l'image dans le petit cadre en bas à droite d'Aladin. On peut penser que le ZoomView n'aura plus la même utilité que pour une image classique. Soit on affiche une imagette plus large que le champ, que l'on adapte suivant le besoin, soit on supprime l'usage du ZoomView pour les images type Healpix.
=> Voir détail des méthodes importantes ci-dessous :

Le principe de fonctionnement serait le suivant:
  a) Le client demande au serveur de lui fournir les triangles HTM (ou équivalents Healpix) pour un champ donné , et pour
     une résolution donnée (ra,dec,resolution,widthScreen,HeightScreen) (normalement le client n'a pas besoin du serveur
     pour connaître les identificateurs des triangles).
  b) Le serveur fournit les triangles. Remarque : pour les basses résolutions, il pourrait facilement les construire à la
     volée en ne prenant la valeur que d'un pixel (un triangle haute résolution contenu dans le triangle basse résolution).
     Mais peut être qu'il vaut mieux les précalculer à l'avance car le volume additionnel n'est pas énorme
     (ex: 1/4 + 1/16 + 1/256). Et pour éviter d'ouvrir trop de sockets, il faudrait pouvoir demander une liste
     de triangles d'un coup, voire ne pas réouvrir le socket à chaque fois.
  c) Le client construit une image rectangulaire à partir des triangles obtenus - sans doute par simple projection
     cartésienne
  d) en cas de panning, le client demande les triangles manquants (en comparant avec son cache permanent)
  e) en cas de changement de résolution, chaque triangle encore visible sera subdivisé en 4 triangles de meilleure
      résolution, demandés au serveur et "incrustés" dans l'image visible à la place du pixel précédent

3) Si les tests sont concluants, il faudra étudier comment peupler la BD avec tout un survey (DSS...) le plus facilement et/ou rapidement possible.


ViewSimple.java : le plus simple est de surcharger la méthode getImgView(g,n)

paint( Graphics g )       : appelé à chaque rafraichissement de l'image
   => getImgView(g,n)  : trace l'image de fond du plan n   <= A surcharger
      => met à jour - si besoin est -  le tableau pixels[] de la portion visible (effectue éventuellement un zoom (voir createZoomPixels())
           (met à jour  MemoryImageSource imgBlink qui accepte la méthode newPixels(pixels), et de la génère Image imgprep qui
           est tracé dans le contexte graphique g
  => paintOverlays(g) : trace les overlays graphiques (catalogues + surcharges graphiques)