-
Notifications
You must be signed in to change notification settings - Fork 76
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
Centralize data label generation #1672
Conversation
Codecov ReportBase: 87.19% // Head: 87.30% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1672 +/- ##
==========================================
+ Coverage 87.19% 87.30% +0.11%
==========================================
Files 95 95
Lines 10049 9979 -70
==========================================
- Hits 8762 8712 -50
+ Misses 1287 1267 -20
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
64fdad8
to
1dfe756
Compare
dac9b24
to
e455196
Compare
app.add_data_to_viewer("spectrum-viewer", data_label) | ||
|
||
else: | ||
raise NotImplementedError("Spectrum2d parser only takes a filename") |
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.
Noticed that Spectrum2d only takes a filename and does not error gracefully if something else is given.
@havok2063 Can you please look over this PR and let me know if it satisfies the acceptance criteria of the original issue? Thanks! |
Editing the snippet to load data from the default specviz notebook to exclude passing the data label fails with an error saying the extension must be specified, is this expected/intended?
|
@kecnry Good catch, definitely not intended. I'll work on fixing that. |
3acde8e
to
c335a05
Compare
@@ -109,7 +110,7 @@ def test_parse_numpy_array_3d(self, imviz_helper, manual_loop): | |||
for i in range(n_slices): | |||
data = imviz_helper.app.data_collection[i] | |||
comp = data.get_component('DATA') | |||
assert data.label == f'my_slices_{i}' | |||
assert data.label == (f'my_slices ({i})' if i > 0 else 'my_slices') |
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 know how to feel about this. I don't like the new labeling behavior wrt loading each slice of cube as an image, but we also have Cubeviz for cube, so maybe not a deal breaker...
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 user can set their own data label, this is just what the default behavior is. The user can create a for loop and within that set the name "my_slices_i".
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 PR doesn't actually introduce that behavior, right? It only changes my_slices_i
to my_slices (i)
(and excludes the (i)
for the first slice to be consistent with other duplicate labels)?
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.
When you load a cube as a series of images, not having number for the first frame seems... wrong.
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.
In line 103:
for i in range(n_slices):
imviz_helper.load_data(arr[i, :, :], data_label=f'my_slices_{i}', do_link=False)
would fix that since all data labels would be unique.
jdaviz/app.py
Outdated
|
||
number_of_duplicates = 0 | ||
for label in self.data_collection.labels: | ||
if data_label in label: |
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.
How robust is this check?
Let's say we already loaded "M31" and "M32" (these are Messier object names). And then we load another unrelated image and be lazy and say data_label="M"
. Will we detect false positive?
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.
It will, "M" will be loaded as "M (2)". How common would that use case be though? And how detrimental would it be for the user to see "M (2)" as opposed to "M"?
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.
It will be super confusing, so maybe ask the POs.
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 call.
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 agree that there are a lot of cases where this can result in confusing behavior. Can regex help us here (to check if the label is identical except for the possibility of an (N)
suffix)? Or maybe for now just check for exact matches since we don't allow deleting the loaded data from the UI itself?
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 can see the workflow Pey Lian mentioned happening more often than not. Seeing "M (2)" would be confusing.
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.
Agree that this would be confusing. I like @kecnry 's suggestions.
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.
Thank you all for the feedback! The latest commit uses regex to determine if a data label already exists in the app. It took a while to get that working with all the different variations of data labels in our tests (names with brackets are now my least favorite), but this should now be ready for review!
We had a meeting about adding benchmarking CI and your number 1 is one of those tickets, so I will not open that can of worms here. |
Test named |
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.
Just a few quick (hopefully) clarifying questions. In general, though, I think we should try to get this in soon and can always iterate going forward - its definitely a big step in the right direction and it is quite difficult to imagine every different case in advance!
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.
Needs a change log before merge, but otherwise I think we should get this in and make tweaks as necessary after it gets some real use. Thanks!
Oh, boy. I think there are a bunch of conflicts from merging Brett's PR. |
128b9f1
to
c946d8f
Compare
@pllim fixed! |
Might have to fix incompatibility with what Brett did.
|
@bmorris3, do any of these errors look familiar to you? |
@javerbukh I'm not sure but it looks a bit like something went wrong in the rebase? For example, this change seems not to know about what's on main. Same here: main branch=new but this branch=old |
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.
Some minor comments.
Description
This pull request is to address inconsistent data labeling throughout jdaviz.
Currently implemented:
Fixes #727
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.