Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Photutils tutorial notebook #3: aperture photometry #4

Closed

Conversation

laurenmarietta
Copy link
Contributor

The third notebook tutorial for photutils, demonstrating methods for aperture photometry.

Some preliminary concerns:

  • Is there anything too important that I left out? The documentation page has a ton of information and examples, and I didn't feel like it would be prudent to include everything. I ended up skipping any demonstrations of alternate methods to define which pixels are in an aperture (i.e. subpixel versus center), more advanced ways of estimating the background within annulus apertures, error estimation, and pixel masking. If one or more of these is really important and should be included, I am happy to do so.
  • And to directly contradict what I just said: Is this notebook too long? It feels a little unwieldy.
  • Also, this PR seems to include the deletion of the 2nd notebooks as part of the commit history, and I'm not sure how to undo this. Since the 2nd notebook hasn't been pushed to master yet, I don't know why its deletion appears as a diff. Any ideas?

Tagging @eteq and @Onoddil for review.

@laurenmarietta laurenmarietta changed the title Photutils aperture photometry Photutils tutorial notebook #3: aperture photometry Dec 12, 2018
@Onoddil
Copy link

Onoddil commented Apr 18, 2019

Apologies for the weird formatting of this 'review', the commit history for this notebook means I can't just review the diff between this branch and master, so I'm afraid I have to do this review by hand. The line in question will be permalinked and the comments/suggestions etc. will follow it.

In answer to your three questions above:

  1. I don't think any of those things are too important to be put into this notebook, but we might think about adding a notebook 3.5 "advanced aperture photometry" which deals with those things. I don't think we care much about how to define a pixel being in an aperture, but the sigma-clipping of annuli (especially in the XDF where you can see in the cells in the notebook quite a few annuli overlap some other source...) and error (uncertainty!) estimation would be good topics to cover, as I imagine that's exactly the sort of thing a person trying to come to python from IRAF/IDL is going to say: "Oh but IRAF/IDL give me the uncertainties and this doesn't, I'm not going to use it!" and we kinda need to make it as easy as possible to just up and use this stuff.

  2. This notebook feels to be about the right length and does the basics of 'how to make and get a flux from an aperture'

  3. I'm not sure what has happened but I'm having to do this odd not-quite-review because a few of your commits are in master, so I think something odd happened where some commits from a previous branch (presumably notebook 1 which is already in I think?) have got caught up and affected files they shouldn't have and it's revealed them in this branch where you're ahead and behind on commits, but I'm really not sure what has actually happened or how to fix it. For a clean final commit you could just rebase and squash the weird history if the end result is fine and we're happy to lose the commit messages, but I'll leave that to @eteq to advise further...

================

"The most common method to measure the flux from a celestial source is aperture photometry,. This kind of photometry measures the amount of flux within a region of defined shape and size (an aperture) surrounding a source. The ideal aperture would capture all of the flux emitted from the desired source, and none of the flux emitted from the surrounding sky or nearby sources. Especially when performing photometry on image data that includes a number of sources with varying size and shape, it is important to perform aperture corrections to account for imperfect apertures and better constrain photometric errors.\n",

Very minor nitpick, but shouldn't this be the flux of a celestial source? If you think yours is right ignore this, but I think this way reads better, with the flux belonging to the source.
It might also be good to add that the flux is measured on an image (of a CCD/detector) with measures the amount of flux within a region of an astronomical image of defined shape and size.
Very minor change too, I think the flux emitted by a desired source and none of the flux emitted by the surrounding sky might be more correct (with the flux belonging to a source), but I'm not 100% on that so again if you think the original way is right then ignore this.

================

"<div class=\"alert alert-block alert-warning\">**Important:** Before proceeding, please be sure to install or update your [AstroConda](https://astroconda.readthedocs.io) distribution. This notebook may not work properly with older versions of AstroConda.</div>\n",

As with the previous review, these boxes don't display correctly for me without empty lines between the <div> blocks and the text.

"<div class=\"alert alert-block alert-warning\">\n",
"\n",
"**Important:** Before proceeding, please be sure to install or update your [AstroConda](https://astroconda.readthedocs.io) distribution. This notebook may not work properly with older versions of AstroConda\n",
"\n",
 "</div>"

================

(I'm going to skip the Retrieve data section as it looks fairly copy/paste similar to the previous notebook but I believe there were some comments on the second notebook in this section -- u.ct being u.electron, the units of the colorbar of the plots, and my generic comment about trying to make the masked data black rather than yellow, at least -- so I'm just going to leave a general comment here that any changes suggested there should be applied to all notebook so this section is the same across them all)

================

"Any aperture object is created by defining its position and size (and, if applicable, orientation). Let's use the `find_peaks` method that we learned about in the [previous notebook](02_photutils_source_detection.ipynb) to get the positions of sources in our data:"

Super minor comment, but I think this should be a previous notebook rather than the previous notebook, as that would then give the flexibility of adding a new notebook at position 2.5 and still have this sentence be fine without editing.

================

(Super generic comment here again about updating all deprecation warnings mentioned in the previous notebook here as well, such as iters to maxiters in sigma_clipped_stats or subpixel=True to centroid_func; any changes made in notebook 2 for the find_peaks section should be reflected in the Creating Apertures section of notebook 3, essentially.)

================


Super minor change but perhaps this (and others below) should be print(variable) instead of just variable? It's the same in a notebook I think but a minor change that would allow a user to scoop up all of the cells and make a .py file without the script falling over, and still allow them to verify they got the same result as the notebook did. Not sure whether that's official policy, but I know I prefer working in python scripts rather than notebooks eventually.

================


Slightly vague comment here, but I'm not quite sure what we're doing at this point. The only context I've been given is that we can create apertures, then we've searched data for sources and plotted them (fine, this part is a replication of a previous notebook and doesn't need much explanation), but perhaps before the Circular Apertures section there could be a mini paragraph along the lines of "Ok, now that we've found our sources, what can we do with them? We want the calculate their fluxes, so we need to get some apertures inside which we can sum the count rates of all of the pixels. We first try circular apertures as simple examples..." or some such; something that semi-reminds the user what they're doing and why it's useful. There basically just isn't much text from you (as the creator/showrunner of the notebook) in quite a few cells of code, and I really liked in notebook 2 how much explanation there was at each step of the way for the user (also stuff like
"Since our elliptical apertures are distinct apertures at distinct positions, we need to do a little more work to get a single table of photometric values.\n",
which is a nice little section of explanation!)

================

"As you can see, these circular apertures don't fit our data very well. After all, this is the Hubble eXtreme Deep Field, so there aren't any nearby Milky Way stars in this image! Let's use ellipses instead to better match the morphology of each galaxy."

Minor comment, but perhaps this line could be something like aren't any nice round nearby Milky Way stars in this image! to make the obvious point more bluntly that stars are round, galaxies are not? Not much of an issue otherwise just thought it'd be good to go a bit overboard with the "these are galaxies in the XDF!" schtick.

================

"segm = detect_sources(xdf_image.data, threshold, npixels)\n",

Similar to above, I think this could perhaps do with a link to notebook 2, with a "see previously for what we did here" to remind the user there's a notebook available to figure out what this thing does and why it's neat. I was briefly thrown as to why the ellipses were all unique until I remembered what detect_sources does myself...

================


Similar to above, print(table) instead of table would be good here.

================


Similar to the ending of the Circular Aperture section, just before this section begins the elliptical aperture section could do with a closing sentence/paragraph, with something like "as you can see these apertures fit much better, combined with the powerful tools available in the detections toolkit and detect_sources much better than circles for galaxies in XDF..."

================

"Fortunately this is extremely easy when we use the [World Coordinate System (WCS)](http://docs.astropy.org/en/stable/wcs/) to produce a WCS object from the FITS header, and then the `to_sky()` method to transform our `EllipticalAperture` objects into `SkyEllipticalAperture` objects."

This could perhaps add produce a WCS object from the header of the FITS file containing our image, to make it a bit clearer that the header relates to the picture you're working on.

================

"* **`data`** - the background-subtracted data array one which to perform photometry.\n",

Super minor typo: data array on which, not one which.

================

"* **`wcs`** (optional) - the WCS transformation to use if `apertures` is a SkyAperture object. \n",

Also super minor: should SkyAperture be inside tick quotes, being a photutils thingy?

================

"phot_datum = aperture_photometry(xdf_image, elliptical_apertures[0]) \n",

Not sure whether this matters much, but I got a warning about the meta attribute being set on the data object but ignored by the function. If the meta flag is used above then I guess this is unavoidable, but otherwise we can likely just remove it to remove a slightly weird not-quite-error message from the notebook.

================

"The `aperture_sum` value is what reports the number of counts within the aperture: 3.47 ct/s.\n",

Just a reminder that if you change the units from u.ct to u.electron, this cell will also need updating.

================

"* Identical apertures at distinct positions (e.g. circular apertures with r = 3 for many sources)\n",

To be consistent with below, the "r = X" entries in this line and the one below it could be tick quoted (r = 3 etc.), as they are in the next section.

================


This cell could again be print(phot_table) instead of just phot_table. It could also perhaps have a little sentence lead in of "now that we've (eventually!) made all of our distinct aperture sums for all of our distinct positions, let's see the results:"

"Let's explore alternate ways to examine this data."

Linked with the above line, this could then also get dressed up a little along the lines of "just printing the results doesn't really tell us much, so let's explore alternative ways to examine these data:" (also these instead of this to be consistent with plural data used throughout the rest of the notebook).

================


These plots (and any below, and any above I didn't notice) either just need a unit change to electrons if the swap is made, or to make use of the fancy metadata units plot code Erik mentioned in notebook 2 to print the units of the datacube.
Also not sure if it's particularly necessary but for explicit statement you could add a y label just of 'Number of sources' or something.

================


Same issue as above and in notebook 2 where the formatting is shown here unless the lines are separated by line breaks. It also seems that <h3> doesn't accept ** so those just need removing I think.

================

"To estimate the local background for each aperture, measure the counts within annulus apertures around each source. In our example, we defined elliptical apertures with `r = 3` to measure the counts within each source. To calculate the background for each source, let's measure the counts elliptical annuli between `r=3.5` and `r=5`."

Not 100% sure this is necessary as I'm not sure what level we're quite pitching these notebooks at, but a very brief half-sentence on what an aperture annulus is and how we can use it to background subtract (get average counts in pixels near but outside of object of interest, assumed to be free of source flux, and subtract that flux from all pixels inside the source aperture) might be good just to give a super quick broad context for the start of a new section.
(it seems there kind of is one of these at
"Now that these background annuli apertures have been defined, we can do photometry with them to estimate the background around sources. The aperture correction is calculated by:\n",
so I'm not sure whether this comment should be changed now but I'm gonna leave it as it was and just suggest perhaps that this latter section is moved up to the previous part I wanted this context in)

================

"- Multiplying the global background mean value times the area of each elliptical photometric aperture, to get the estimated background value within each aperture\n",

Should background value be something like the count rate of the background or the background count rate? value sounds a bit vague, could do with being a little bit more specific I think. Are you worried it gets confused with count rate within each annulus in the first step?

================


Here and cell two down should maybe be print(variable) instead of just variable again.

================

"# Calculate the mean background level (per pixel) in the annuli \n",

Might be good here to have a brief little sentence about the fact that because these data are already background subtracted we'd hope that the background is tiny and oh look it is, just to reassure users that this function does have use honest and that 0.0007 ct/s is fine as a value to get... I also think this should possibly have units u.electron / u.s / u.pixel (or u.ct) as that makes it clear that this is the count rate in a single pixel.

================

Hopefully this review is ok and makes sense - let me know if you need any clarification of anywhere I've tried to link to or not formatted right, etc.

@laurenmarietta
Copy link
Contributor Author

Thanks so much for this great feedback, @Onoddil!

Again, per the new plan for finishing up these notebooks, I am going to close this PR - any future discussion will take place on the spacetelescope/notebooks repo, on the new PR thread: spacetelescope/notebooks#101

I have implemented almost all your thoughts, though, and I very much appreciate your attention to detail. I am choosing not to use some of your suggestions though, including:

  • The places where I don't explicitly put the Astropy tables in a print() statement is because printing an Astropy table returns a hunk of ASCII text, while just returning the table renders a lovely HTML-formatted table, so I'm planning to keep those the way they are.
  • I couldn't find a particularly good way to move the bulleted list explanation of aperture correction up to the top of that section, but I did reword a few things to hopefully make it flow better. Let me know if that still isn't to your liking.
  • I tried to implement your last comment about specifying the background count rate units as u.electron / u.s / **u.pixel**, but that quickly became very messy, since the aperture area should really be in (u.pixel)**2, so I am thinking I will just leave it as it is as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants