Hi Boud,
I've been wondering about the optimal pixelization scheme of the sphere a couple of weeks ago and since I've send to you my own implementation of the Healpix pixelization scheme written (generally) in C (according to astro-ph/0409533) but compatible with GNU c++ compiler here I'd like to comment on some comments that can be found in the source code.
And since you don't like private, closed conversations I also cc this letter to shape-univ.
1) First of all healpix is not stupid :)))) - it's cool because pixels have the same area which is not always the case (e.g.. quad-cube pixelization used with COBE data), because it's hierarchical and isolatitude of course, however the first and the last features are also common in other pixelization schemes.
1.1) But also very important thing is that it is more less "equi-angular" - i.e. the angular distance from pixel to pixel is more less constant. But obviously the exact "equi-angular" solution does not exist.
2) Now the my CPEDS library for doing useful stuff - and especially the pixelization.c has more useful functions so probably I should update the version I've send to you. i.e. - conversions from RING to NESTED and vice versa - calculation of ring given pixel and vice versa (in both nested and ring orderings) - estimated pixel size (maybe not that useful) since it may be probably just as well estimated from 4PI/N_pix.
3) The main point I wanted to come up with the new idea for pixelization scheme was the thing I addressed in point 1.1. But also the following 3 drawbacks of this scheme, namely:
3.1) the pixel shape dramatically varies from pixel to pixel. this is what I didn't like because of e.g. CMB lensing studies where the morphology at small scales would be very important - but of course this can be overcome with sufficiently oversampling the pixelization by increasing the Nside parameter to meet the Nyquist conditions.
3.2) the number of pixels in a ring does NOT gradually rises with increasing \theta (in spherical system definition consistent with HEALPIX - i.e. theta = 0 at North pole). Instead it only rises in the top (bottom) part of the north (south) polar region. This is certainly unnatural thing. since all the latitudes in equatorial (roughly from 41 deg to 180-41 deg regions are represented by the same amount of pixels in longitude) !! This is not the case e.g.. in he GLESP (Gauss-Legendre) or Igloo pixelization schemes.
3.3) It has an axial symmetry (since it has a poles equator, rings, etc). And why the CMB sky should know anything about the symmetry ? In particular why should it have an axial symmetry ? So naturally the solution would evolve into direction of platonic forms like tetrahedron, cube, ... oops it ends at icosahedron. And since we need a pixelization with number of pixels something like few Mpixels the 20 pixels of icosahedron is not enough. My idea of tetrahedron based pixelization system was just driven from this point of view that there should be no preferred directions in the sky. The system would gain higher resolution by looking for directions equally separated from neighboring directions (initially defined by axis of tetrahedron). This concept fails, of course because such a solution does not exist.
Max Tegmark also went in this direction inventing the icosahedron pixelization system which is the next step after the quad-cube system, but each triangle is divided in other way.
Anyway, at this time I see no point of terrible importance to force the idea of the tetrahedron pixelization system so I drop this case. rather it would be interesting to implement other pixelizations systems into the isolat packet.
pozdr, Bartek