[Shape-univ] couple of comments on the pixelization schemes

[Boud Roukema]

Hi Bartek, all, :)

On Wed, 9 Nov 2005, Bartosz Lew wrote:

> 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.

Good :). That puts more pressure on me to integrate your code into the
"isolat" package. :)


> 1) First of all healpix is not stupid :)))) - it's cool because pixels

Of course - IMHO we all agree on this. It's cool. :)

> 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.

Hmm. AFAIK that's correct.

> 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.

OK

> 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.

Well, oversampling is what i assume is always done.

> 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.

Well, i agree with the motivation.


> 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.

Do you implementing "existing" pixelisation systems?

Well, i see nothing against it, i just don't see it how it would be useful
in practice. Unless someone is going to reanalyse the *raw* data of WMAP
or Planck - and i mean the really raw data, before it has been converted to
the healpix projection/pixelisation - then *re*formatting an observational
map from the healpix system to a new system is only going hide the effects
(if any) of the healpix system, it's not going to remove them. (And moreover,
it will necessarily introduce some additional numerical error.)


Hmm... However, given that a lot of interest is in the smaller angular
scales, the question is how much different pixelisation methods could
cause wrong conclusions to be made...

If you're going to use these different systems e.g. on a hypothetical data
set, which is projected/pixelised in different ways, then that could potentially
be an interesting paper. :)

OK, i'll put your isolat addition higher up in my todo list :)

pozdr
boud