Stars Center on the stamps

[MickaelRigault]

Hello guys,

I am working with Romain Graziani for using PIFF with ZTF and I was wondering if it would be possible to center the stars on the stamps created using the inputfile.makeStars.

Here is an illustration. The "stamp" are created by including the fact that the (0,0) is the center of the pixel and not its lower-left, so (with dx=dy=piff__stamp_size=15)

def stamp_it(array, x0, y0, dx, dy):
    """ """
    lower_pixel = [int(x0-dx/2+0.5), int(y0-dy/2+0.5)]
    upper_pixel = [int(x0+dx/2+0.5), int(y0+dy/2+0.5)]
    x_slice = slice(lower_pixel[0], upper_pixel[0])
    y_slice = slice(lower_pixel[1], upper_pixel[1])
    return array[y_slice].T[x_slice].T

It's not the end of the world but I think it would make sense to have the star in the center.

Cheers Mickael

[rmjarvis]

I'm pretty sure makeStars does choose the stamps so that the given position (from x_col, y_col) is as close as possible to the center of the stamp. I suspect the confusion is that these positions are assumed to be FITS-style positions, not numpy. That is, the center of the lower left pixel of the full image is considered to be (x,y) = (1,1), not (0,0).

These are the positions that show up if you open the image in, say, ds9 or some other standard astronomical image viewing software. And notably, (1,1) offset from what you get from things like matplotlib's imshow.

[MickaelRigault]

It definitely could be that.

Should I change my code such that the conversions are RA,DEc-> x_col, y_pos in FITS-style or is there a way to tell PIFF that the values I am giving are numpy ?

I would prefer the latter as I think numpy formating is more standard (and matchs with matplotlib). But I could make the trick inside my code. Thanks

[MickaelRigault]

I am now shifting the x_cos, y_col by -1 to follow the fortran/fits format when creating the catalog that enters PIFF.

It solves the issue.

[rmjarvis]

Good. I'd much rather keep the convention of matching other astronomy software than some particular plotting package, so I think we should leave it as is. Especially since most input catalogs (e.g. any from SExtractor or the LSST stack) will be using this convention, not the numpy one. (I.e. your convention is very much not more standard.)

However, we could consider adding optional parameters xoffset and yoffset, which you can set to 1 as a way to apply an offset to the input positions. This way, you wouldn't need to rewrite new catalogs if you for whatever reason made catalogs with the numpy convention.

[MickaelRigault]

That could be an idea, and indeed, numpy convention might actually not be the standard in astronomy.

[RobertLuptonTheGood]

The Rubin code sets the centre of the bottom-left-hand pixel to be (0.0, 0.0), which is off-by-one from FITS (but consistent with 0-indexing in C and python)

[rmjarvis]

Ah, good to know. Thanks.