timmonko / napari-ndev Goto Github PK

For example, currently adding the 'ome.tif' file extension will continually tack it on for each widget that saves the image, such that you end up with images that say 'ome.tifome.tif', etc. While this likely is ok for functionality, this looks silly and sloppy.

Widget width is wider when layers have long names prior to loading the widget. Width of widget appears to match maximum length of layer names.

Detected when downloading 0.0.4 on a colleagues Mac. The default on windows is int32 for labels layers. This image type is independent of how the underlying image layers are loaded or the original file type.

This occured when trying to use only 1 root from a 2 channel image. Python did not give an error. Solved by turning off keeping original images in this context.

Useful in two scenarios: 1) increasing inputs to train ML classifiers. 2) when an image is not processed via the workflow, but user wants to still use it in the future.

I think the over dependence on AICSImage for metadata is preventing flexibility with cropping and also probably related to #15 because the OmeTiffWriter is receiving metadata that is no longer valid.

Increase flexibility with acquiring metadata for saving with aicsimageio.OmeTiffWriter. This will likely require pulling metadata from the napari viewer and layers.

The biggest challenge may be collecting the image layers without pulling back the raw aicsimage.data into the OmeTiffWriter.

Currently, save location of apoc classifier is in working directory, which can be inconvenient and confusing if running strictly from napari.

title

Figure out how to make a more flexible save method

Look more closely into layer.save.
Currently uses default builtins plugins, but provides no other arguments.
May need to write own writer component to the plugin.
However, this may not matter for the intended use which is using the labels and images stored in the folder for further batch processing.