-
Notifications
You must be signed in to change notification settings - Fork 74
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
Colorbar on histogram #2517
Colorbar on histogram #2517
Conversation
But you have pan/zoom now. 😉 |
Another thing to consider (if coloring lines is ever supported upstream): we could color the stretch curve itself (and perhaps have it always enabled)... but I don't think that switching that to scatter with the plan to support custom splines would be worth it. |
Promising!! |
This comment was marked as resolved.
This comment was marked as resolved.
9fc2c03
to
1f8ba78
Compare
Codecov ReportAttention:
... and 1 file with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
@camipacifici , the colorbar now should be available in Plot Options. The concept notebook is still useful if you want to quickly run through different Plot Options settings via API and see how it affects the colorbar, but not compulsory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced scatter is the solution we want, but at least it allows us to test out the rest of the logic and hopefully we can swap out whatever is used for plotting (either before merge or as a follow-up).
@observe('is_active', 'image_color_mode_value', 'image_color_value', 'image_colormap_value', | ||
'image_contrast_value', 'image_bias_value', | ||
'stretch_function_value', 'stretch_vmin_value', 'stretch_vmax_value', | ||
'stretch_hist_nbins', 'stretch_hist_zoom_limits') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should be affected by stretch_hist_nbins
or stretch_hist_zoom_limits
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You tell me. Colorbar needs to track changes in the histogram X-axis too. So unless these nbins also trigger one of the other things it is already listening, I need it. Not sure what stretch_hist_zoom_limits
is doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since x
is currently sampled on the bins (see conversation below), we do need to keep stretch_hist_nbins
so that the resolution of the colorbar is controlled by the same input. But I don't see any need for stretch_hist_zoom_limits
(which just changes which data is included in the histogram, but shouldn't affect the bins themselves (unless perhaps that would break if some bins on the extremes are unused - worth testing first!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I think we still need it because the display histogram X-axis values change when you toggle follow zoom, so we also need to update the colorbar.
with self.stretch_histogram.hold_sync(): | ||
color_mode = self.image_color_mode_value | ||
interval = ManualInterval(self.stretch_vmin.value, self.stretch_vmax.value) | ||
contrast_bias = ContrastBiasStretch(self.image_contrast_value, self.image_bias_value) | ||
stretch = stretches.members[self.stretch_function_value] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with a lot of this logic being shared with the drawing of the stretch function, should those be in the same method? We could even consider having the same switch toggle both of them (and perhaps be on by default).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are a bit different. You listen to layer.state
but I cannot because the state updates lags behind so I need to grab from plugin settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so can the stretch function read from plugin settings as well to be consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't self.stretch_function_value
from the plugin already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sorry, I meant can't drawing the stretch function be done the same way as you are doing here so that the code can be consolidated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe but I don't want to complicate it more in this PR. We're already behind schedule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consolidating will make maintaining and building on top of this significantly easier though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still not sure if consolidation won't introduce new bugs. _update_stretch_curve
loops through for layer in self.layer.selected_obj
for reason I do not understand, while _update_stretch_histogram_colorbar
does not because I disabled it in multi-select mode. So maybe when you are looping through layers, it makes sense to access layer.state
instead of plugin values. But I cannot do that in the colorbar because for reason I do not understand again, layer.state
lags behind in the colorbar (i.e., if I change from Gray to Viridis, colorbar only changes to Viridis after I change it back to Gray again).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
decided to defer code consolidation and removing any multi-layer support to a follow-up effort.
299fe92
to
b8eb5d3
Compare
Rebased on top of @haticekaratay 's work. |
jdaviz/configs/default/plugins/plot_options/tests/test_plot_options.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! We'll consolidate the code with other recent PRs in a follow-up PR (hopefully soon 🤞 )
devdeps failure is unrelated RTD failure is also unrelated but I should probably patch it sooner than later as a separate PR (#2533). |
and add concept notebook with possible colorbar implementations [ci skip] [rtd skip]
because Kyle probably added this because I have no idea what it is doing but I see it in the old diff. Co-authored-by: Kyle Conroy <kyleconroy@gmail.com>
and some cleanup in that same test module
3c2f401
to
2753608
Compare
Rebased again to resolve change log conflict. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as expected in all of my testing, nice work! Do we still want to keep the concept notebook?
I found it useful to access the Plot Options programmatically with it and see the popped out colorbar changes in real time. But it is not necessary for this feature to work, so if you prefer to not have it, I can delete it from this PR. Please let me know. |
Description
This pull request is a different approach to encode colorbar information on the Plot Options histogram. Previous attempt to use pure bqplot (#2514) failed. This one lifts code from glue-core to compute the colors using matplotlib and then throw them on the bqplot histogram directly.
Known issues due to it listening to too many things at once, I think. Not sure how to make it cleaner:
Change log entry
CHANGES.rst
? If you want to avoid merge conflicts,list the proposed change log here for review and add to
CHANGES.rst
before merge. If no, maintainershould add a
no-changelog-entry-needed
label.Checklist for package maintainer(s)
This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.
trivial
label.