[api question] from_fits_image

[bmatthieu3]

This method creates a moc from a fits image. You have the possibility to pass a mask. With a mask, the algorithm will reproject to the sky only the pixels that are inside the mask. We then create the moc from all these skycoords (using from_lonlat/from_skycoord)

What order should we consider for the returning moc ?

What is currently done is the following:

The moc order is the min between the one given by the user and the healpix order corresponding to one pixel in the image. The last one is computed. I originally did that because if the user put an order of let's say 20, the resulting moc will have lots of holes around the small pixels i.e. the order is too precised for the image pixel size.

Other api options I see (I am sure there are other possibilities) would be:

• The order of the moc is the one given by the user. We therefore accept the holes in the moc if the user gives a too precised order with respect to the image pixels.
• Same as above but we autorize max_norder=None and if so, we compute the max_norder to be equal to the hpx order of a pixel image
• We return a moc created from hpx cells containing the skycoords at the hpx order of a pixel (not the one user specified). But we set the max order of that moc to the max_norder given by the user.

[fxpineau]

How do you ensure that the resulting MOC covers the full pixels (not only pixels centers), regardless of the resolution you choose?

But, to answer your specific question: among the 3 options, I tend to favor the last one, possibly degrading the MOC if user_order < pixel_order.

Another solution may be to create a "pixel MOC" (using the Z-order curve in the image XY-space) and use a path_along_xy_multiorder_pixels that we de-project to get spherical polygons, and then make the union of the MOCs of those spherical polygons. The step of path_along_xy_multiorder_pixels would be smaller or equals to the size of the original image pixels. It will not be fast, but it will be more accurate.

(Depending on the performances, a better option would be to use the footprint finder in #122 to get the STC-S footprint of the image and then compute the MOC from STC-S).

[bmatthieu3]

How do you ensure that the resulting MOC covers the full pixels (not only pixels centers), regardless of the resolution you choose?

We do not, I think it is a limitation indeed and maybe be we can add that to the doc. Something like, only pixels centers are unprojected and we assume a pixel roughly correspond to the healpix order in the sky. Your solution tackle the problem and is more accurate but indeed it may be a bit slow too (but the speed decrease can be acceptable, it is worth testing it I think in the future).

[ManonMarchand]

There is also https://docs.astropy.org/en/stable/api/astropy.wcs.WCS.html#astropy.wcs.WCS.calc_footprint that could be useful? It gives the corners of the image in sky coordinates.

[ManonMarchand]

(Depending on the performances, a better option would be to use the footprint finder in #122 to get the STC-S footprint of the image and then compute the MOC from STC-S).

Could it be an other example rather than a full feature?

[tboch]

not, I think it is a limitation indeed and maybe be we can add that to the doc. Something like, only pixels centers are unprojected and we assume a pixel roughly correspond to the healpix order in the sky. Your solution tackle the problem and is more accurate but indeed it may be a bit slow too (but the speed decrease can be acceptable, it is worth testing it I think in the future).

Holes in a MOC generated from an image is really not what a user would expect. Thus, I have a strong preference for a more accurate solution, even if detrimental to the overall speed.

[tboch]

(Depending on the performances, a better option would be to use the footprint finder in #122 to get the STC-S footprint of the image and then compute the MOC from STC-S).

That could be an option, but you are then totally ignoring pixels with NaN values.