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
