-
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
Add stretch bounds tool to plot option histogram viewer #2513
Add stretch bounds tool to plot option histogram viewer #2513
Conversation
Codecov ReportAttention:
... and 6 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
Remove debugging prints Add test
# Add the stretch bounds tool to the default Plot viewer. | ||
self.stretch_histogram.tools_nested.append(["jdaviz:stretch_bounds"]) | ||
self.stretch_histogram.toolbar = NestedJupyterToolbar(self.stretch_histogram.viewer, | ||
self.stretch_histogram.tools_nested, | ||
[]) |
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.
we might eventually want to generalize this as a method (or have the init take options for the tools), but this is probably ok for now if this is the only case we're modifying?
FYI Jenn said she probably won't be able to get to making an icon for this until next week. |
I changed this to update the closest bound to where the user clicks, and to enable clicking+dragging. Way more performant than I was worried it would be, video below: Screen.Recording.2023-10-19.at.11.54.31.AM.mov |
Curious... what happens when someone puts one line on top of another, how do you decide which line they are clicking on? |
It seems to Just Work (tm) actually, I don't think it will let you drag the VMax below the VMin, it switches between them as you drag past. |
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.
This really works very nicely once we get the throttling tuned right for large images. Do we want to change the color between inactive/active in this PR or consider that follow-up?
Co-authored-by: Kyle Conroy <[email protected]>
f4dfd1b
to
cadd0ec
Compare
I'll see if I can do the color quickly this afternoon. |
f81c6ad
to
bbd0603
Compare
@kecnry Colors change now, not sure if this is the best way to do it but these lines weren't a subclass of any of our marks, so I just did it this way 🤷 . |
This also changes the color of the stretch function itself, which isn't ideal. We probably want that to always be blue now since that will only be "active"/"clickable" with another tool and only for splines (in the future). We might eventually want to generalize the slice mark to also get the "out-of-bounds" logic, but for now just a custom class or even just a private attribute to check ( |
I was thinking that, although you aren't directly changing that line, it does update when you change vmin and vmax, that it might make sense to have it change color as well. Basically "things that will be affected by using this tool change color." I'm open to changing it though. |
Update jdaviz/configs/default/plugins/plot_options/plot_options.py Co-authored-by: Kyle Conroy <[email protected]> Codestyle
bbd0603
to
f2fc309
Compare
Add missing colon Codestyle
Alright, I updated so that the stretch curve color doesn't get updated. |
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.
There was no where to suggest it, so I just pushed a commit that changes the curve to the same "inactive" blue (always). Once that supports dragging as well, we can do the same color toggling as here.
This works great and is a super elegant solution! Curious to see if we need to fine-tune the throttling when using on super large images, but we can iterate on that easily going forward.
04ce780
to
5eff644
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.
The only small issue I ran into was that there is some funky behavior when you click a min/max line and drag it around, when it surpasses the previous maximum and becomes the new maximum. The second line will move even when not being dragged:
Screen.Recording.2023-10-20.at.12.55.26.PM.mov
EDIT: We had a discussion offline about changing the logic of this from 'inactive bar becomes active' to 'active bar becomes new min/max' which would improve the jumpiness when dragging the bar around, but that doesn't need to block this PR.
When you click the home button the bars disappear. Also you can see in this video, do vmin and vmax start overlapping and you have to 'shake' the second bound loose to have access to both bars?: Screen.Recording.2023-10-20.at.1.05.24.PM.mov |
Home button is a known bug, see #2506 |
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.
Approving, but to summarize some offline discussion pertaining to my review:
- My comment about the jumpiness of the bars can be fixed in a follow up but doesn't need to block this PR. It would entail changing the logic when vmin>vmax from the active bar switching, to the definition of the active bar switching (vmin becomes vmax, rather than the selection changing)
- The home button problem is an existing issue
- The overlapping bars issue i mentioned is related to Non-repeatable vmin vmax[BUG] #2526
Opening as draft since I'll need a test and changelog entry.