Add image profile class #833
Conversation
|
👍 This is almost independent of image and angles, so this could be changed to a more general "Profile1D" class. Not sure, maybe keep as-is for now? |
There was a problem hiding this comment.
I've left a bunch of inline comments.
Only one is really a bug (profile -> profile_err copy & paste error), the rest is up to debate (do what you think best for now, no need for discussion / further review).
Adding one example in the docstring of high-level docs to advertise this would be great!
| """ | ||
| Image profile class. | ||
|
|
||
| The image profile data is stored in `~astropy.table.Table` object, with the |
There was a problem hiding this comment.
I'd suggest to put a Parameters section, even if there's just one parameter in __init__.
Keeping the table column description in the docstring is fine, I think.
There was a problem hiding this comment.
Does this work for tables with columns that don't have units?
Or are there certain requirements on units for certain columns?
(my suggestion would be to not hard-code ImageProfile specific behaviour, and make this more of a general Profile1D class)
There was a problem hiding this comment.
I agree there's nothing special about this class, that would restrict the use to image based profile measurements. For now I'd like to keep it as is, but let's keep in mind the class could be used for acceptance or other profiles as well...
|
|
||
| x_j = \sum_i x_{(j - i)} h_i | ||
|
|
||
| Where :math:h_i are coefficients of the convolution kernel. |
There was a problem hiding this comment.
Does this work? I think backticks are needed, no?
:math:`h_i`
Is it really useful to give the general formula how 1D convolution works?
Why not just say "convolution"?
| radius : `~astropy.units.Quantity` or float | ||
| Smoothing width given as quantity or float. If a float is given it | ||
| interpreted as smoothing width in pixels. If an (angular) quantity | ||
| is given it converted to pixels. |
There was a problem hiding this comment.
If a float is given it interpreted as smoothing width in pixels.
I don't think that's true, you always execute:
radius = np.abs(radius / np.diff(self.x_ref))[0]
width = 2 * radius.value + 1
I think I would prefer to only support float width in pix here, because smoothing is done in pix.
If you keep the quantity width, you should document that width = self.x_ref[1] - self.x_ref[0] is used to convert to float.
Looking at http://docs.gammapy.org/en/latest/api/gammapy.image.SkyImage.html#gammapy.image.SkyImage.smooth I see that the links to uniform_filter and gaussian_filter in scipy aren't working.
Probably it has to be ~scipy.ndimage.uniform_filter and ~scipy.ndimage.gaussian_filter?
Can you please fix this there and here?
| """ | ||
| Image profile error quantity. | ||
| """ | ||
| return self.table['profile'].quantity |
There was a problem hiding this comment.
profile -> profile_err
Add a test that catches this?
| Parameters | ||
| ---------- | ||
| **kwargs : dict | ||
| Keyword arguments passed to plt.plot() |
There was a problem hiding this comment.
Link to plot function in MPL, so that people can quickly look up the valid parameters?
|
|
||
|
|
||
| @requires_dependency('scipy') | ||
| def test_smooth(self): |
There was a problem hiding this comment.
Add some more tests and asserts for smooth?
E.g. Gauss smooth is never executed I think -> does it work?
Does profile_err get filled with reasonable values?
|
@cdeil Thanks for the review, I've addressed your comments with the latest commits. I'll merge once Travis-CI passed. |
|
Travis fails were unrelated. |
This PR implements a generic
ImageProfileclass, which offers plotting, smoothing and renormalization methods. The main data structure is an astropy table, which stores the coordinate valuesx_reforx_minandx_maxand the profile data valuesprofileandprofile_err.