Feature request: ability to plot slices of a DataCube

[followthesheep]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

It would be useful to be able to plot slices of a DataCube object. There are capabilities to plot predefined maps, but it would be useful to be able to plot individual spectral channels too.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Possibly use the same system as Map when returning a spectral channel so features like plotting would work.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Currently, I am slicing the flux object from the DataCube casting the slice into a numpy array before using imshow. Note that using imshow directly on the slice does not work because of astropy Quantities.

Additional context
Add any other context or screenshots about the feature request here.

[albireox]

Hi @followthesheep,

Can you provide a bit more details on how you imagine this happening? Do you want to create a Map-like object based on a single spectral channel (e.g., the 6564A channel from the data cube) or do you want to provide a spectral range and create a map based on the sum or median or the channels in the range? I can see the former case being dangerous from a science point of view but overall I think this is an idea worth exploring.

Can you provides some more details of the science goal you're trying to achieve? That would help us define the best way to implement this.

[havok2063]

In one example he showed me it was something like

cube = Cube('8485-1901')
slice = cube.flux[10]

which returns a DataCube instance of shape (34,34). And he wanted to plot it similar to plotting a Map or Spectrum. This is one example of a single wavelength slice, but I can imagine generalizing for cases of subsets involving a wavelength range, where we apply some default aggregation or smoothing, with other options.

[albireox]

Without having given it a lot of thought I think we want to be careful about that. A single channel may be representative for quick visualisation but it's not something that should (ever?) be use for science. I think we want to implement this but checking with the DAP guys to be sure don't facilitate a misuse of the data.

[followthesheep]

I'm not really sure I understand the argument about 'misusing' the data. I find it incredibly useful to use single channels of IFU data. It is often useful for very narrow lines or to look for systematic uncertainties like bad pixels. I find it helps to understand the data better. Integrating multiple channels is also useful, but not in all use cases. This may not be a feature that MaNGA wants to implement, but I would like to suggest that it is a mode that users are likely to want, and may implement themselves.

…

On Wed, Jan 9, 2019 at 1:38 PM José Sánchez-Gallego < ***@***.***> wrote: Without having given it a lot of thought I think we want to be careful about that. A single channel may be representative for quick visualisation but it's not something that should (ever?) be use for science. I think we want to implement this but checking with the DAP guys to be sure don't facilitate a misuse of the data. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#592 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHfP-Pb9Af-5Nb-kZRiy7WweER6rw78ks5vBkpmgaJpZM4Z0eSK> .

[kbwestfall]

My unsolicited 2p: What Tuan is suggesting is perfectly reasonable, but a couple thoughts that the Marvin folks should weigh in on:

• If it's straight-forward to implement something like this, I would actually encourage Tuan to try doing so himself in a branch and then submit a PR. Our resources for Marvin development are really limited, and we'd like to promote community involvement in adding features. This seems like a pretty good example of a feature that an interested member of the community could contribute.
• The great thing about Marvin is that you don't have to have the data locally. At the same time, I think we want to be careful with implementing functionality that puts us down a path of rewriting existing tools. Things could snowball from plotting a single channel as a map, to integrate channels, to integrating channels over specific apertures, to integrating over channels that are different for different spatial positions, etc... If you want to scan through channels in an individual datacube, it might make more sense to download the cube and use something like QFitsView or ds9. But if you're interested in plotting hundreds of channels across many galaxies/cubes, then I agree this would be good to have in Marvin.

[havok2063]

I think viewing a cube slice is reasonable but I think this could creep into becoming a cube viewer, with all the encompanying functionality, which I think we want to avoid. I think we also want to maintain the differentiation from a DAP MAPS, which is an official product we trust and a cube slice, which I'd caution against using. We could create a new simple Slice class. @followthesheep I think what @albireox means is that we don't want people to use single slices for their science (e.g. around H-alpha) when we have carefully controlled DAP maps that already handle systematic uncertainites. All of our maps have applied masks which flag for a variety of systematics and quality issues, which you can look up and analyze.

I think we shouldn't make it impossible to plot a slice, so if there's something like Quantities currently preventing that, we should look into it. @followthesheep I tried this and it seemed to work. Is this what you tried that created an error with the Quantities?

from marvin.tools import Cube
cube = Cube('8485-1901')
slice = cube.flux[10]
import matplotlib.pyplot as plt
plt.imshow(slice.value)

Once we start talking about adding a plot method to DataCube then we open up the whole worm can @kbwestfall mentions.