-
Notifications
You must be signed in to change notification settings - Fork 1
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
Fix invalid Shape.TheC value #5
Fix invalid Shape.TheC value #5
Conversation
The* values should always be non-negative, -1 is invalid.
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.
Confirmed as part of the testing of glencoesoftware/ome-omero-roitool#38 that the current release of the QuPath OMERO extension sets theC
to -1
for each Shape exported to OMERO. With this PR included, theC
is set to 0
and the ROIs can be exported as OME-XML using the current HEAD of ome-omero-roitool
.
Is setting this value unconditionally to the first channel the expected beahvior? An alternative default would be not to set TheC
which means the ROI would be applied to all channels.
int will always be serialized, but Integer will only be serialized if not null.
With defb154, |
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 the last commit, using a multi-channel multi-Z fluorescence images hosted on OMERO and exporting annotations created from QuPath, I get the following behavior
All theC
, theZ
and theT
properties are now unset and the ROIs will be interpreted as applying to all planes.
A possible follow-up would be to look into populating the TheZ
value in QuPath and translate it accordingly when exporting to OMERO. My understanding is that the Z/T index was not properly populated prior to this PR so this is not a regression. It would be useful to have a second opinion from @muhanadz or anyone involved in the QuPath workflow.
Noticed while testing glencoesoftware/ome-omero-roitool#38:
ome-omero-roitool will get a companion PR shortly, but this should at least prevent the extension from sending an invalid value. Repeating the same steps as above with this change and a different image should successfully export the ROI to OME-XML.