-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Lack of rotation when plotting rotated fields of view with NDCube #99
Comments
If you look closely the ticks are rotated, so the plot knows the coordinate system does not align to the image. What needs changing here is the defaults for the tick labels and probably a faint grid to make it more obvious that the image and the coordinate system are not aligned. The plot will not and should not rotate the image to the coordinate system. |
Having said that, work is currently being done on astropy to make WCSAxes default to standard decimal notation for arcsec by default. (astropy/astropy#7318) |
@Cadair so this is really an issue with WCSAxes and not ndcube? Maybe this is not a problem for astronomical images, but for solar observations I think it would be really useful to have the option of rotating the image so that the coordinates are aligned with the figure axes. It is very common to work with multi-telescope observations, and superimposing two observations on the same coordinate system is really useful. |
@tiagopereira overlaying non-aligned data is not an operation that WCSAxes / matplotlib can or should just handle, it's one for a package like reproject which you can use to do that for display purposes with solar data. I think there is an NDCube issue here, in that we should have some more sane defaults for the tick labels and grids etc, i.e. match the default settings of |
@Cadair thanks for the link to reproject, which seems to be very neat (although I worry about all the package fragmentation: astropy / reproject / sunpy / irispy / ndcube). However, reproject re-grids the images, which is not exactly what I had in mind. In particular, for visualising with matplotlib some re-gridding/interpolation would of course be necessary, but ideally we would still preserve the original, non-interpolated data for any other operations. One could for example plot an AIA image and superimpose an IRIS slit-jaw image, keeping their different pixel scales and not necessarily scaling up or down to match pixel-by-pixel. Of relevance to NDCube is that it appears that when the coordinates are not aligned with the image, its slicing
|
What about Regarding the point about sane defaults for the tick labels and grids, |
@DanRyanIrish the aspect ratio is just the symptom, the problem seems to be that What I'm doing in the commands above is trying to crop a similar image to what Baptiste plotted. If you see his figure, the x axis goes from ~-7' to -5', and y from ~3' to 4.5'. In my |
@tiagopereira You do appear to have found a true bug in As for the package fragmentation, that is a design decision for Python, it's a very modular ecosystem. Given it's very easy to install packages and have packages depend on one another, I really think it's a source of strength once you are used to it. Overplotting images with different pixel scales I think is possible using matplotlib, but you need to re-grid them to align them before you plot them, because matplotlib does all the drawing in pixel space. We should look into wrapping this functionality up into IRISPy or sunpy where appropriate. |
Ah, I better understand now. Thanks @tiagopereira. This reveals that Perhaps yourself or @BaptistePellorceAstro would be interested in contributing to Any thoughts @Cadair? |
I don't think ndcube should use reprojection, that is a bigger picture problem that needs looking at in sunpy. As much as I do like the idea of having a reprojection aware overplotting helper in SunPy. See issue #100 for discussion on the |
-- "I don't think ndcube should use reprojection, that is a bigger picture problem that needs looking at in sunpy. As much as I do like the idea of having a reprojection aware overplotting helper in SunPy." Agreed! |
Agree that allowing for general WCS coordinates, reprojection can be quite complex. But most of the cases people deal with in solar observations should not be that complicated -- it is just a rotation away. E.g., most space data comes from Earth orbiting satellites where the reprojection is simple. Many (most?) ground-based telescopes of the 1m+ class have alt-az mounts and no derotator, meaning that the solar image rotates with time in the CCD plane. If we also want to use NDCube for those data (I think we should), then this rotation is necessary for every frame. This is going beyond the scope of the original discussion, but I think it is important to make a distinction between this rotation of the coordinate space for plotting and cropping purposes vs for storing and manipulating the data. Not only can the rotation operation (interpolation) be destructive on the data, storing rotated data can result in much larger file sizes because the array sizes increase (factor of 2 for 45 degrees, much more when you consider IRIS SJIs that cover a wide raster). For "plotting and cropping" I feel this is very much on the realm of NDCube. |
I think that plotting and cropping are distinctly different things. Cropping is certainly within the scope of I completely agree on with @tiagopereira on the usefulness of rotating for plotting purposes. I think it's a question of where that core functionality lives. I think due to its complexity, and because work has already been done on this topic for My discussion here really has gone down the rabbit hole to the point of being off topic. My main point is that being able to access this functionality through |
[I wrote this before Danny's comment] So, in general, sunpy (core) has tried to work on the principal of doing everything in coordinate space without having to rotate (reproject) the data. And yes, while I realise that rotation and arbitrary reprojection differ in complexity, they are effectively the same underlying operation, so for the most part they are equivalent in this discussion. [side note, for ndcube it would be a lot easier to just use the reproject package than trying to convert I don't think you need reprojection for cropping in physical coordinates, you just need to make sure you take the maximal coordinate box as discussed here and in #100. (As for generating masks of coordinate regions, this is super easy using As for plotting, I think it would be quite easy to write a overplotting script for any |
I'd just like to thank @BaptistePellorceAstro for raising this issue and @tiagopereira for his contributions to it. As we can see it's sparked some very interesting discussion about |
@Cadair sorry, I seem to have missed your earlier post about package fragmentation and plotting. I happen to be responsible for maintaining the python distributions in our group, and from that perspective it is often annoying to have many packages to install/update. Also I get similar feedback from new users that are trying to install in their own hardware. But anyway... About matplotlib plotting in pixel scale, this is not always the case. For example |
By testing some data to check if coordinates are well represented with NDCube instance, we found that for rotated fields of view, X and Y axis are not representing usual coordinates that we use. We tried with iris_l2_20150304_160141_3824263489_SJI_1400_t000 data coming from a 45 degree's rotated field of view, and you can see, below, the result we have. In this case, the images should be rotated by 45 degrees counter-clockwise.
The text was updated successfully, but these errors were encountered: