Closed martinschorb closed 2 years ago
There was still a bug in the code that made add_bdv_image
fail when not passing an argument for menu_name
.
I have fixed this now, but I would suggest to still pass menu_name
to the function; otherwise it will just default to "images"
, which is pretty non-descriptive.
OK, it seems to run now. 👍
Is there an option to make add_bdv_image
skip the copy process if the input is already a MoBIE-compatible container (N5/Zarr)?
I would envision that the function will behave as a wrapper for the metadata and directory structure creation. As @K-Meech 's project creator it would either link or move existing BDV images into the project.
Is there an option to make
add_bdv_image
skip the copy process if the input is already a MoBIE-compatible container (N5/Zarr)? I would envision that the function will behave as a wrapper for the metadata and directory structure creation. As @K-Meech 's project creator it would either link or move existing BDV images into the project
No, that's not supported by add_bdv_image
and should go into a separate function. In general I don't really like the linking approaches as it will make publishing a MoBIE project not possible; everything should be contained in the MoBIE directory so that it can be uploaded to s3.
Moving the image data is of course fine, but I am a bit hesitant, because it changes the input data to the function, which users might not expect.
Implementing functionality for this would be simple though:
You can base it on add_bdv_image (which calls add_image
internally), but instead of calling import_image_data move the data.
I will have a look.
I found some inconsistency:
It seems that import_image_data
and the DownscalingWorkflow it calls also creates some kind of basic metadata.
metadata_dict
which seems MoBIE-specific. I will work around it and generate this partially populated dataset
template separately. But maybe it makes sense to pull it out of there and include it into this MoBIE codebase.
It seems that
import_image_data
and the DownscalingWorkflow it calls also creates some kind of basic metadata.metadata_dict
which seems MoBIE-specific.
No, this is not MoBIE specific at all but just the metadata that will be used to create the bdv xml file (more precisely to create the transformation and resolution metadata in there). (Or alternatively it will be used to generate the multiscales
metadata for ome.zarr) .You don't need this if you move the bdv xml file as well as the n5 file.
OK, sorry. I was mislead by an error message complaining about a missing source entry in the dataset. And thus I thought that this was created during th downsampling. But in fact it happens before...
What's the rationale behind requiring the same source and the internal ViewSetup name (in the XML)? Is it the BDV source names that it retrieves when opening an XML that need to be consistent with the source name in the view?
I have trouble with the N5 and XML automatically being renamed to "Setup0" because of that and then obviously the ImageLoader
part in the XML no longer works. So I indeed have to modify the XML in any case.
Is it the BDV source names that it retrieves when opening an XML that need to be consistent with the source name in the view?
Yes, exactly.
So I indeed have to modify the XML in any case.
Yes, that will be necessary.
In the end it was rather easy. Pulling it out into other functions would have required massive code duplications. Hence I added it into add image
fixed by #45
Hi,
I tried to use
add_bdv_image
with minimal input to include an existing n5 into a MoBIE project. I provided the xml path, output folder and dataset name as minimal (positional and thus required) parameters.It fails during validation because something with the view seems wrong.
Is there anything else I need to provide? Or what would be a clean way to quickly populate a MoBIE project from existing n5 data?
I thought that this would maybe a way to skip manually managing the datasets and sources.