-
Notifications
You must be signed in to change notification settings - Fork 31
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
PlateAcquisition filtering with plate display #542
Conversation
Thanks @Tom-TBT |
Hi Will, omero-web/omeroweb/webgateway/views.py Lines 64 to 67 in ab843f1
Maybe something with the try except that flake8 isn't handling well with imports.
Anyway, I read about |
Yes, just use |
NB: this import block has been removed in https://github.com/ome/omero-web/pull/531/files where we cleaned up a lot of the legacy Python2/3 compatibility code. If you merge |
I was wrong. There is still the issue when there's a different number of WellSample per Run between Wells. Note that the issue existed before these changes. Discussing it locally, we figured that there are several use cases where this occurs (we have such datasets):
Here is the test data for the problem I described bellow Four wells, and a first Run with 3 sample in C3 & D4, and 1 sample in C4 & D3. Selecting the second Run, there are three fields listed (when there should be only one). First field shows C4 & D3, second shows nothing, third shows C3 & D4: This is because the Field# is matched to the WellSample index (indexing done per Well):
Selecting Acquisition 2, the index is in the range[2,4], given by omero-web/omeroweb/webclient/forms.py Lines 384 to 388 in 4d8d25e
So in the case of the second run:
where indexes are used by this query: omero-web/omeroweb/webgateway/plategrid.py Lines 49 to 61 in 4d8d25e
I am investigating how I can solve this issue. Now trying with HQL queries to get the index adjusted to the Run:
|
So, @Tom-TBT you want the number of Fields for any Acquisition to be the As was mentioned yesterday, some tests are failing at https://merge-ci.openmicroscopy.org/jenkins/job/OMERO-test-integration/382/#showFailuresLink They are mostly failing with:
with also one of:
|
Tom, in the screenshot above where you've annotated the screenshot in Red and Green
Obviously the UI changes would need a bit of thought about the best way to show the different Acquisitions that the Fields belong to, so it doesn't need to happen in this PR (although could maybe add it as a tooltip in this PR to help debugging)? |
Yes exactly. I implemented that in my last commit in
Yes, that's what we should see now. And with the fix on @sbesson |
Some notes (for myself at least) about the UI changes you proposed Will: Can add Run information in here. omero-web/omeroweb/webgateway/views.py Lines 1833 to 1839 in 99aebd2
Something like omero-web/omeroweb/webclient/templates/webclient/data/plate.html Lines 270 to 273 in 99aebd2
|
This looks good now, using the sample file above:
|
omeroweb/webgateway/plategrid.py
Outdated
""" | ||
Constructor | ||
|
||
param: plate_layout is "expand" to expand plate to multiple of 8 x 12 | ||
or "shrink" to ignore all wells before the first row/column | ||
|
||
acqid: the acquisition ID. Using it, the field index (fid) must | ||
be in the range [0, max_sample_per_well] for that acquisition. |
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.
Great that this is documented here, but I think more extensive explanation could be useful, since I'm not sure I would understand the behaviour here if I hadn't also read the code.
Using acqid
changes the behaviour of the field index so that it's not the absolute field index but the relative field index for the fields of each Well after filtering by acquisition.
if (acquisition === undefined) { | ||
acquisition = 0; | ||
} | ||
var url = opts.baseurl+'/plate/'+pid+'/'+field+'/'+acquisition+'/'; |
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.
Minor suggestion: Could you maybe just omit acquisition
from the URL if it's not defined? Using 0
instead of an ID is a little confusing.
And the same is true elsewhere where acquisition should be None
if not used instead of 0
: e.g. The default (null) argument above acqid=0
feels like it should be acqid=None
to indicate no filtering?
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.
Looks good, thanks 👍
Code looks good to me |
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/how-does-omero-assign-wellsample-to-fields/100110/3 |
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/creating-multiple-plateacquisitions/106140/2 |
Follow up on https://forum.image.sc/t/omero-web-plate-display-with-multiple-plateacquisition/90071
Rather than switching the plate display using the JSON api (my understanding is that it would require rewritting quite of JS to populate the plate with the results), I figured that I was able to pass the plateAcquisition ID (already exists and in use to filter the content of the "bird eye" in
plate.html
).Passing the plateAcquisition ID down to
PlateGrid
, it adds a filter on which WellSamples are loaded.plate.html
does the rest by populating only the Wells that contains WellSamples. Further selection of a well will show in thebird eye
only the WellSample of that acquisition (as it already did).If no plateAcquisition is passed (that's the case when the plate is selected in the tree), then all wellsample are loaded (as it did before). The difference in this case is that there is no filter on the "bird eye" when selecting a well, so all wellsamples are shown (which is the expected behaviour).
For it to show the plate when there is more than one run, I just removed the logic that prevented the plate to be loaded with more than one run (which was not preventing extra loading, since everything was loaded when selecting a plateacquisition)
The
field index
also seems to work as expected, without additional change.