Tkakar/cat 673 create builder for seg mask #92
Conversation
|
@NickAkhmetov not sure why the tests are failing, I removed the parts for |
| def __init__(self, base_conf: ConfCells, epic_uuid) -> None: | ||
|
|
||
|
|
||
| class EPICConfBuilder(ViewConfBuilder): # pragma: no cover |
There was a problem hiding this comment.
I wasn't sure if we wanted the EPICConfBuilder to extend the base ViewConfBuilder (i.e. in case there are any additional EPIC-specific patterns that become apparent) but I think it should be fine; I think the extra _epic_uuid logic you included in the base builder takes care of my initial concerns.
| seg_path = ( | ||
| 'https://assets.hubmapconsortium.org/c9d9ab5c9ee9642b60dd351024968627/' | ||
| 'ometiff-pyramids/VAN0042-RK-3-18-registered-PAS-to-postAF-registered.ome_mask.ome.tif?' | ||
| 'token=AgzQXm7nvOW32vWw0EPpKonwbOqjNBzNvvW1p15855NoYglJxyfkC8rlJJWy8V6E8MeyXOwlpKdNBnHb5qnv7f8oeeG' |
There was a problem hiding this comment.
GitGuardian nagged me about including the token in the previously committed code, even though they expire quickly 😆
I believe we can access the token via self._groups_token like the superclass does now that we're extending it: https://github.com/hubmapconsortium/portal-visualization/blob/main/src/portal_visualization/builders/base_builders.py#L106-L107
| for obj in segmentation_objects: | ||
| dataset.add_object(obj) | ||
|
|
||
| # TODO: what happens if these views already exist , and if there are other views, how to place these? |
There was a problem hiding this comment.
Good question, this is definitely important to determine! While we may be able to handle the more basic image-only assays like Histology/PAS microscopy by appending to existing configurations, given that we anticipate there will be segmentation masks for various assays and that we'll have a few different base confs as a result, my understanding is that we may need to re-set up views and coordinations from scratch for those. We should discuss with @keller-mark to confirm/see if he has any alternative suggestions.
src/vis-preview.py
Outdated
|
|
||
| args = parser.parse_args() | ||
| marker = args.marker | ||
| # epic_builder = args.epic_builder | ||
| epic_uuid = args.epic_uuid | ||
| # parent_uuid = args.parent_uuid # this may not be needed, as the --url provides the parent dataset json? |
There was a problem hiding this comment.
The parent_uuid is necessary for visualizing image pyramid support datasets, since the logic in builder_factory expects parent is not None for those cases and performs an assaytype lookup on the parent to determine which specific image pyramid builder to use (to handle evolution of how image pyramids were handled over time): https://github.com/hubmapconsortium/portal-visualization/blob/main/src/portal_visualization/builder_factory.py#L75-L76
There was a problem hiding this comment.
Overall, it looks good! I'm a bit concerned about introducing those optional dependencies since they might cause some issues downstream; I was also thinking we may want to have both dev and prod options for running the vis-preview script, so we don't have to keep updating the default values in the future, perhaps defaulting to dev and using the prod values with a --prod argument.
|
@NickAkhmetov thanks for reviewing, do you think the Github workflow should be updated to use |
requirements-prod.txt
Outdated
There was a problem hiding this comment.
These requirements are dev-only since they're related to formatting, test running, etc - I don't think they're relevant outside of this environment.
I think that approach makes sense, i.e. updating the script's handling of this to match the other parameters? |
|
|
@tkakar You did add it to the script! I was replying to this piece of your previous message:
I believe we should be able to provide the epic_entity json via the portal-ui back-end, i.e. extending the logic here to fetch the EPIC entity if an |
Creates the epic-builder to update the vitessce configuration of a parent dataset for the provided segmentation mask.