Radial plots showing all the pixels

[hcferguson]

The IRAF imexam radial plots show all the pixels, rather than binned by radius. This is useful for evaluating the quality of centroids or PSF fits. My suggestion is that this be the default for python imexam. Binned plots with uncertainties might be useful too, but I think are typical inspection.

[sosey]

@hcferguson is this close to what you were thinking?

In [8]: a.set_plot_pars('r','pixels',True)
set radial_profile_pars: pixels to True

In [9]: a.imexam()

[hcferguson]

Possibly. It looks like the pixel positions are binned in radius, which makes me think this is relative to a center that might not have been computed from either a centroid or a fit? Or maybe it's just the precision of that fit is truncated? I often use this kind of plot as a visual way to assess how well that centering is working. I think maybe in imexam the 'r' key did the same sort of centering as the 'a' key, and then plotted relative to that center. Is that what you are doing?

I think maybe there was another version that would show the Gaussian fit on top of this. Or maybe that was the default. I don't have the manual in front of me.

[sosey]

@hcferguson Not quite binned in radius, you're seeing those columns because of the integer pixel radial calculation - so the lines are pixels on the x or y (0/90) axis and not between.

Here's the process I used to create that graph:

• Using the pointer location, recenter using a 2d gaussian fit in a 10 pixel box size
• The integer value of that location is then used to cut out a smaller data array from the main image
• The radial distance from center of all pixels from the integer center in that box is computed
• If background subtraction is on, I calculate the mean local background in a circular annulus area and subtract that from the flux
• plot the points

if the user wanted binned points, instead I collect all the pixel flux within integer radial bins and sum that value for plotting (that was the plot you saw in the demo). I would have thought of this as an enclosed flux measurement. I'm not currently using sub-pixel measurements and interpolation but that could be added if that option is desirable.

You're correct, I haven't had time to add the option of over-plotting a model fit to the radial profile yet, the pieces are there I just need to add the machinery to this function. Otherwise, this is doing the same thing as the 'a' and 'r' keys from iraf. Both are using photutils for the aperture photometry and I recently switched from my own model fits to astropy fits now that they are available.

These are the defaults in the parameter list for the radial plots:

{'background': [False, 'Subtract background? [bool]'],
 'center': [True, 'Solve for center using 2d Gaussian? [bool]'],
 'fitplot': [False, 'Overplot profile fit?'], (not implemented)
 'fittype': ['Gaussian2D', 'Profile type to fit (Gaussian2D)'],
 'function': ['radial_profile'],
 'getdata': [False, 'return the plotted data values'],
 'magzero': [25.0, 'magnitude zero point'],
 'marker': ['o', 'The marker character to use, matplotlib style'],
 'pixels': [True, 'Plot all pixels at each radius? (False bins the data)'],
 'pointmode': [True, 'plot points instead of lines? [bool]'],
 'rplot': [8.0, 'Plotting radius in pixels'],
 'skyrad': [10.0, 'Background inner radius in pixels, from center of object'],
 'title': [None, 'Title of the plot'],
 'width': [5.0, 'Background annulus width in pixels'],
 'xlabel': ['Radius', 'The string for the xaxis label'],
 'ylabel': ['Flux', 'The string for the yaxis label']}

The star in question: In [5]: a.panto_image(530,414) In [6]: a.zoom(4)

The line fit:

and the binned example: where that first point at zero is actually the central pixel value, which should be the max: [528:533,412:417] max: 543.842957 <-- as taken from the numpy max in a 5pixel box

[larrybradley]

I think the issue is that the radius values here are always relative to an integer pixel location (the center of the central pixel). However, the true centroid is most likely not exactly at an integer pixel location.

[sosey]

@larrybradley correct, I measure the true centroid to make sure I'm starting from the pixel which contains the center, but then I pull the integer pixel values. If you want a plot from the centroid position out through the radius at subpixel steps I'd have to move into subsampling the image and interpolating flux. Is that what people prefer?

[hcferguson]

@sosey No...don't subsample. Put the points at radii that are (x_p - x_c) where x_p is the center of each pixel and x_c is the true centroid.

[larrybradley]

@sosey All you need to do is calculate the radii from the centroid (i.e. shift the radial distances), but keep the flux values the same.

[sosey]

thats what I'm doing, let me look at the code again after my meeting

[sosey]

how about this? Looks like I still had the new center from the chopped array when I computed the radii so I added back in the fractional offset

[hcferguson]

Looks good to me.

[sosey]

@hcferguson great. I'll merge this after I fix a couple more bugs I found, let me know if you see anything else that looks off :-) (yay users!)

[larrybradley]

👍

[sosey]

oh yah - also, I apparently forgot that I did implement a moffat, polynomial 1D (with n degrees, not composite) and apparently started a 2d airy disk as well. The things you find when you look at your code after a long time..

[sosey]

fixed in ab12f90422fdd95a71f6660cb8a1208a66e32bd8