You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running the enhancement algorithms, the plot that map.plot() produces and the plot that plt.imshow(map.data) shows are very different, and the imshow one is the correct one. This can be fixed with map.plot(norm=None) or with map.plot_settings["norm"] = None, which is how the radial module modifies the output map to deal with the issue. I think it makes sense for the user to not have to manually supply a norm=None to the plot command.
At least the enhance.mgn and enhance.wow algorithms need to be updated to normalize properly. I'm just not sure how to handle that issue since they are able to take either a map or an array. I guess that it would just need an if type(input) is <> check of some kind.
I suspect that there are other places where this normalization issue is present, too. Note that this bug happens in the ReadTheDocs example gallery, which is where I noticed it. This functionality is already present in some of the functions in the radial module following #205 .
Looks like that functionality was only added in the most recent update to these functions. Maybe it would be better to add support for maps/ better support for arrays instead? What do you think?
Describe the bug
When running the enhancement algorithms, the plot that
map.plot()
produces and the plot thatplt.imshow(map.data)
shows are very different, and the imshow one is the correct one. This can be fixed withmap.plot(norm=None)
or withmap.plot_settings["norm"] = None
, which is how theradial
module modifies the output map to deal with the issue. I think it makes sense for the user to not have to manually supply a norm=None to the plot command.At least the
enhance.mgn
andenhance.wow
algorithms need to be updated to normalize properly. I'm just not sure how to handle that issue since they are able to take either a map or an array. I guess that it would just need anif type(input) is <>
check of some kind.I suspect that there are other places where this normalization issue is present, too. Note that this bug happens in the ReadTheDocs example gallery, which is where I noticed it. This functionality is already present in some of the functions in the
radial
module following #205 .To Reproduce
See https://docs.sunpy.org/projects/sunkit-image/en/stable/generated/gallery/radial_gradient_filters.html
Screenshots
https://docs.sunpy.org/projects/sunkit-image/en/stable/generated/gallery/radial_gradient_filters.html
This is supposed to be an improvement on the raw data, but it is completely uncalibrated.
System Details
Required Dependencies
#####################
astropy: 5.3.4
numpy: 1.24.4
packaging: 21.3
parfive: 2.0.2
Optional Dependencies
#####################
asdf: 2.15.2
asdf-astropy: 0.4.0
beautifulsoup4: 4.11.1
cdflib: 1.2.1
dask: 2022.7.0
drms: 0.6.4
glymur: 0.12.8
h5netcdf: Missing h5netcdf>=0.11; extra == "timeseries"
h5py: 3.7.0
lxml: 4.9.1
matplotlib: 3.5.2
mpl-animators: 1.1.0
pandas: 1.4.4
python-dateutil: 2.8.2
reproject: 0.12.0
scikit-image: 0.19.2
scipy: 1.9.1
sqlalchemy: 1.4.39
tqdm: 4.64.1
zeep: 4.2.1
Installation method
pip
The text was updated successfully, but these errors were encountered: