-
Notifications
You must be signed in to change notification settings - Fork 7
prepare_label_group
should handle mismatches of label_name & the zattrs name of the label
#619
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
Comments
Broader discussion: Should the prepare_label_group do any kind of attrs validation to ensure it's a valid OME-Zarr attr? Would also make sense |
|
As of 9e11b56:
As of 48a014b:
|
Closed within #613. I'm re-opening, to make sure we agree on point 3 above:
|
Seems fair to me. Is there a reasonable behavior we'd do if a user doesn't provide zattrs? We couldn't know things like pixel sizes etc. |
This is the current function signature: def prepare_label_group(
image_group: zarr.hierarchy.Group,
label_name: str,
label_attrs: dict[str, Any],
overwrite: bool = False,
logger: Optional[logging.Logger] = None,
) -> zarr.group: Given these arguments, there's no attribute that we can directly infer. This is not about things like pixel sizes, but really about any attribute. Things change if we make a further assumption, namely that we have access to the image being labeled (either by assuming we can go up two levels in the Zarr hierarchy and find it, or by having an additional function argument). new_datasets = rescale_datasets(
datasets=[ds.dict() for ds in ngff_image_meta.datasets],
coarsening_xy=coarsening_xy,
reference_level=level,
remove_channel_axis=True,
)
label_attrs = {
"image-label": {
"version": __OME_NGFF_VERSION__,
"source": {"image": "../../"},
},
"multiscales": [
{
"name": output_label_name,
"version": __OME_NGFF_VERSION__,
"axes": [
ax.dict()
for ax in ngff_image_meta.multiscale.axes
if ax.type != "channel"
],
"datasets": new_datasets,
}
],
} This option for sure looks interesting, in view of factoring out a functionality which is already repeated in two tasks (note however that this is not how things happen e.g. in https://github.com/fmi-basel/gliberal-scMultipleX/blob/nar-fractal/src/scmultiplex/fractal/relabel_by_linking_consensus.py#L157-L174). If we take this latter option, then the |
Thanks for the further explanations. I'd say we take this on board for a future refactor of label writing. For now, we made the prepare_label_group function more robust, that should be the limit of the 0.14.0 scope. |
Issue originally reported by @nrepina
If we copy a label image and give it a new name, the zattrs we get from an old label image also contain a
name
attribute => potential mismatches.Example code
Now the label image will be named label_name + '_consensus' in the folder, but the metadata still contains only label_name.
We can debate who's responsibility this should be. The easy fix is to add a line like this:
But we tend to want to remove more of this metadata handling from tasks and put it into the helper functions.
At a minimum,
prepare_label_group
should give a warning if there is this mismatch, but maybe even just fix it and give priority to the explicitlabel_name
parameter.The text was updated successfully, but these errors were encountered: