Skip to content
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

Render nans as 'bad' in mpl cmaps when mode='colormap' #2427

Merged
merged 2 commits into from
Aug 17, 2023

Conversation

bmorris3
Copy link
Contributor

@bmorris3 bmorris3 commented Aug 7, 2023

Description

By default, image viewers cast NaNs to zero before applying a colormap. This prevents the use of the matplotlib "bad" feature. For each colormap, values above or below the colormap vmin/vmax are rendered with an optionally specified value, and "bad" values (usually nans) are rendered by a third value:

import matplotlib.pyplot as plt

plt.cm.viridis
Screen Shot 2023-08-07 at 12 39 22

By default, bad is color='k', alpha=0, but this can be changed with:

plt.cm.viridis.set_bad(color='r')

which allows users to clearly visualize nans efficiently and without special handling.

Glue currently forces nans to zero before they are converted to colors by the colormap:

data[np.isnan(data)] = 0

which prevents the user from ever making use of the bad functionality.

This PR allows the user to set a private attribute on the CompositeArray class called _set_nans_to_zero. When True, the behavior is unchanged. When set to False by a user, nans are not forced to zero, and the bad values are rendered as described by the mpl colormap. An example is shown below using Imviz from jdaviz:

Screen Shot 2023-08-07 at 12 43 43

@@ -137,7 +138,8 @@ def __call__(self, bounds=None):
data = interval(array)
data = contrast_bias(data, out=data)
data = stretch(data, out=data)
data[np.isnan(data)] = 0
if self._set_nans_to_zero:
data[np.isnan(data)] = 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was only introduced in fa60bf1 for compatibility with Astropy; if we can reproduce what the issue with Astropy was, preserving NaN may perhaps be made the default again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@astrofrog Any memory/tips of what we should check? Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was actually that astropy did not preserve NaNs and then started to so it's not an issue with astropy as such - but more that when you do color compositing you don't really have the option to give NaN values their own color since each channel has only one color assigned to it. So I think it's as I mentioned on the call - for multi-color compositing we should always set NaNs to 0 and for the colormap we could never set it to zero.

@bmorris3
Copy link
Contributor Author

As of e01db76, nans are forced to zero when mode='color', and no zeros are forced when mode='colormap'.

@bmorris3 bmorris3 changed the title Add private option to render nans as 'bad' in mpl cmaps Render nans as 'bad' in mpl cmaps when mode='colormap' Aug 15, 2023
@astrofrog
Copy link
Member

It looks like some tests will need to be updated

@bmorris3
Copy link
Contributor Author

@astrofrog All fixed!

Copy link
Member

@astrofrog astrofrog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants