Tell image server to consider 3 channel uint8 data as RGB #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
...even if the microservice is used. This affects the image types that are available, see https://qupath.readthedocs.io/en/stable/docs/starting/first_steps.html#setting-the-image-type. If `rgb(false)` was passed, brightfield image types are never available, so workflows that rely on a brightfield image can break.
sbesson
approved these changes
Sep 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
...even if the microservice is used. This affects the image types that are available, see https://qupath.readthedocs.io/en/stable/docs/starting/first_steps.html#setting-the-image-type.
If
rgb(false)was passed, brightfield image types are never available, so workflows that rely on a brightfield image can break.The issue and fix can be tested with any uint8 3-channel image on any server we've previously used for testing this extension. Standard
CMU-1.svsor similar would be a suitable file to have imported.Without this change, opening the test image via the 0.4.3-gs extension should prompt for an image type, but only allow non-brightfield types. So as in this screenshot, but with the first row of options missing:
https://qupath.readthedocs.io/en/stable/docs/starting/first_steps.html#setting-the-image-type
This is because the prompt for an image type specifically does not allow brightfield types to be selected if the image server does not identify the image as RGB:
https://github.com/qupath/qupath/blob/main/qupath-gui-fx/src/main/java/qupath/lib/gui/panes/ImageDetailsPane.java#L388
The change here tells the image server to report an image as RGB if the microservice was not used (as before) or if there are exactly 3 uint8 channels and the microservice is used. With this change, the prompt for an image type should allow all of the brightfield options to be selected (as in the linked screenshot above). I would expect no other change in behavior, as this is intended not to affect how image data is actually retrieved from OMERO.