-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Adding colormap "curve" to Plot Options stretch histogram #2390
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2390 +/- ##
==========================================
+ Coverage 90.52% 90.62% +0.09%
==========================================
Files 159 159
Lines 18236 18217 -19
==========================================
Hits 16509 16509
+ Misses 1727 1708 -19
☔ View full report in Codecov by Sentry. |
self._stretch_histogram_needs_update = False | ||
|
||
@observe('stretch_vmin_value', 'stretch_vmax_value', 'layer_selected', | ||
'stretch_function_value', 'stretch_hist_nbins', |
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 think this is redundant with the add_observe
above (although we might want a comment here as well that we are listening to stretch_function_value
.
'stretch_function_value', 'stretch_hist_nbins', | |
'stretch_hist_nbins', | |
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.
Done, thanks.
# Import here to prevent circular import (and not at the top of the method so the import | ||
# check is avoided, whenever possible). | ||
from jdaviz.configs.imviz.plugins.viewers import ImvizImageView | ||
from jdaviz.configs.cubeviz.plugins.viewers import CubevizImageView | ||
|
||
if ( | ||
not isinstance(self.viewer.selected_obj, (ImvizImageView, CubevizImageView)) or | ||
not hasattr(self, 'stretch_histogram') | ||
): | ||
# don't update histogram if selected viewer is not an image viewer, | ||
# or the stretch histogram hasn't been initialized: | ||
return |
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 love that this is duplicated logic, maybe we should put this in a re-usable method/property? Or even in ViewerSelect
itself so we could do self.viewer.selected_is_image_viewer
?
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.
Moved 👍🏻
mark_label = f'{mark_label_prefix}{layer.label}' | ||
mark_exists = mark_label in self.stretch_histogram.marks |
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.
What is the benefit of tracking per-layer curves? Just to future-proof if we ever support showing the histogram for multiple layers? If we don't need that now, this can simplify greatly by creating the mark in the init with the rest of the other marks, always modify that existing entry, and not have to worry about re-ordering the marks.
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.
That's the use case I have in mind. Curves for multiple layers might be helpful for RGB work (cc @PatrickOgle).
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.
the whole histogram would need to be updated for that though... is it worth the overhead now if we're not sure how that will work yet?
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.
If it's already implemented, what's the harm in keeping it?
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 think we will want a more general solution that handles the histogram in the same way and there is no good way to actually test this implementation as-is and it adds quite a bit of extra code that we're not 100% sure if we'll ever use 🤷♂️
|
||
# create the new/updated mark following the colormapping | ||
# procedure in glue's CompositeArray: | ||
layer_state = layer.state.as_dict() |
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.
does this provide any benefits over referring to layer.state.contrast
etc below? My only thought would be that you ensure all state properties are accessed simultaneously 🤷♂️
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.
No important differences. Switching to layer.state.
.
I don't have a good intuitive sense for what I'm looking at here, but it seems useful for people who do. I think it might be better to have this be a toggle in the UI ("Show colormap curve" or something), which would add context for people who might not immediately know what this line on the histogram is. |
The colormap curve hurts my head. It makes me think too much. Why can't we just have a colormap bar like everyone else? |
This could be a nice way to explain what it means, but it also would cost vertical space (you already have to scroll between the controls that modify the curve and the histogram itself, unless you pop it out), so that concerns me a little. I suspect people who want it would know what it is, and people who don't would just ignore it? 🤷♂️ This might be a good thing for user-testing and feedback though.
I agree for just trying to go from color -> value a colorbar is more intuitive and common, but the eventual goal/request here is to be able to also create and edit custom splines for RGB image creation to manually tune the balances for each layer/filter. |
curve_y = stretch(curve_y, out=curve_y, clip=False) | ||
curve_y = layer_cmap(curve_y)[:, 0] | ||
|
||
if not mark_exists: |
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.
Would it make more sense to have this after the following for loop, so we're not immediately checking a mark we just created that already has the right x and y?
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.
Good idea, done!
edf21f2
to
c65035a
Compare
Added a toggle option for the stretch curve in the plot options histogram (thanks for the suggestion, @rosteen!): hist-stretch-func-toggle.mov |
c65035a
to
47a0a55
Compare
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.
LGTM now, I like the toggle. Tested in the standalone and notebook, didn't manage to break it. I don't have strong opinions on the last ongoing implementation discussion so I'm approving.
@@ -381,6 +393,13 @@ def state_attr_for_line_visible(state): | |||
self.stretch_vmax = PlotOptionsSyncState(self, self.viewer, self.layer, 'v_max', | |||
'stretch_vmax_value', 'stretch_vmax_sync', | |||
state_filter=is_image) | |||
|
|||
self.stretch_curve_visible = PlotOptionsSyncState(self, self.viewer, self.layer, |
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.
do we want to add this to the user API (and then API docs)?
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.
Done.
Dev failure is unrelated, and being addressed upstream here: astropy/astropy#15233 |
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 created a follow-up ticket to either finish multi-layer support (for the histogram and vertical marks as well) or to remove the unused logic here. 🐱.
Can you also please just add an entry for stretch_curve_visible
in the class-level docstring before merge?
add stretch_curve_visible to plot options api, docs
99b4329
to
27c0b59
Compare
Description
This PR is the first towards @PatrickOgle's feature request for Photoshop's "curves" tool. Curves shows a histogram of the pixel counts overlaid on a normalized representation of the colormap scaling. I've added a similar curve to the Plot Options histogram for image layers in Imviz or Cubeviz:
hist-stretch-func.mov
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.