sunpy / sunraster

A SunPy-affiliated package which provides tools to analyze data from spectral data from any solar mission.
BSD 2-Clause "Simplified" License
20 stars 24 forks source link

Plots generated from `.plot` methods look odd in jupyter notebooks and regular matplotlib #241

Open mwcraig opened 1 year ago

mwcraig commented 1 year ago

Describe the bug

When I run the plotting examples from the documentation, e.g. from here, in jupyter lab the generated plots have multiple overlapping elements, including widgets that don't work.

EDIT: The plots look about the same in matplotlib run from ipython. Screenshot added.

To Reproduce

This code is from https://docs.sunpy.org/projects/sunraster/en/latest/data_types/spectrogram.html#plotting:

import numpy as np
data = np.ones((3, 4, 5))
import astropy.wcs
wcs_input_dict = {
    'CTYPE1': 'WAVE    ', 'CUNIT1': 'Angstrom', 'CDELT1': 0.2, 'CRPIX1': 0, 'CRVAL1': 10, 'NAXIS1': 5,
    'CTYPE2': 'HPLT-TAN', 'CUNIT2': 'deg', 'CDELT2': 0.5, 'CRPIX2': 2, 'CRVAL2': 0.5, 'NAXIS2': 4,
    'CTYPE3': 'HPLN-TAN', 'CUNIT3': 'deg', 'CDELT3': 0.4, 'CRPIX3': 2, 'CRVAL3': 1, 'NAXIS3': 3}
input_wcs = astropy.wcs.WCS(wcs_input_dict)

from sunraster import SpectrogramCube
my_spectrograms = SpectrogramCube(data, input_wcs)

import astropy.units as u
from astropy.nddata import StdDevUncertainty

uncertainties = StdDevUncertainty(np.sqrt(data))
# Create a mask where all pixels are unmasked, i.e. all mask values are False.
mask = np.zeros_like(data, dtype=bool)
my_spectrograms = SpectrogramCube(data, input_wcs, uncertainty=uncertainties, mask=mask)

my_spectrograms.plot() 

See next section for screenshot.

Screenshots

In Jupyter Lab notebook

Cursor_and_Untitled_ipynb_-_JupyterLab

In matplotlib MacOSX backend from ipython

Figure_1

System Details

sunpy Installation Information

General

OS: Mac OS 13.3.1 Arch: 64bit, (arm) sunpy: 4.1.6 Installation path: /Users/mattcraig/mambaforge/envs/sunraster-dev/lib/python3.11/site-packages/sunpy-4.1.6.dist-info\ python: 3.11.3

Required Dependencies

astropy: 5.2.2 numpy: 1.24.3 packaging: 23.1 parfive: 2.0.2

Optional Dependencies

asdf: 2.15.0 asdf-astropy: 0.4.0 beautifulsoup4: 4.12.2 cdflib: Missing cdflib!=0.4.0,>=0.3.19; extra == "timeseries" dask: Missing dask[array]>=2.0.0; extra == "dask" drms: Missing drms>=0.6.1; extra == "net" glymur: Missing glymur!=0.9.0,!=0.9.5,>=0.8.18; extra == "jpeg2000" h5netcdf: Missing h5netcdf>=0.8.1; extra == "timeseries" h5py: Missing h5py>=3.1.0; extra == "timeseries" lxml: Missing lxml>=4.8.0; extra == "jpeg2000" matplotlib: 3.7.1 mpl-animators: 1.1.0 pandas: Missing pandas>=1.0.0; extra == "timeseries" python-dateutil: 2.8.2 reproject: Missing reproject; extra == "docs" or "map" scikit-image: Missing scikit-image>=0.16.0; extra == "image" scipy: 1.10.1 sqlalchemy: Missing sqlalchemy>=1.3.4; extra == "database" tqdm: 4.65.0 zeep: Missing zeep>=3.4.0; extra == "net"

Other

ndcube: 2.1.1

Installation method

git checkout

nabobalis commented 1 year ago

I think is is a result of picking the default unit as metres instead of nm.

I can try work out how to fix that.

Cadair commented 1 year ago

The default unit is unfortunately picked by astropy.wcs.WCS, which defaults everything to SI. What we need to do is write a unit-preserving WCS wrapper in astropy core, because by the time NDCube / WCSAxes get's given the WCS object there's no indication that it used to be in nm left anywhere.