This repo is currently primarily only a Fiji Drag & Drop handler for OME-Zarrs.
If the dropped target is not recognized as a OME-Zarr v0.3 - v0.5 resource, it does nothing.
There are several options for what Fiji can do after dragging & dropping an OME-Zarr folder.
Users can select the default drag & drop behavior via Plugins -> OME-Zarr -> Drag & Drop behavior
The options are:
- Open the highest available single-resolution image in ImageJ.
- Open a matching single-resolution image in ImageJ (initial default). Users can preset a maximum image width, and Fiji will open the highest available single-resolution image that is not larger than the preset width. This is useful for avoiding the loading and opening of excessively large images. Fiji simply chooses an appropriately sized level from the resolution pyramids (multiscales) of the dropped OME-Zarr.
- Open as a multi-resolution source in BigDataViewer. This is useful for large OME-Zarrs. Channel names, colors, contrast limits, and the time point are automatically extracted from the OME-Zarr metadata, if available.
- Show a dialog with all available opening options.
Note: BigDataViewer is part of Fiji, so there's no need to install anything extra. It is an image(s) viewer especially designed for chunk-based, multiresolution data, designed around the principle of loading only pixels that are needed for the current display of the image(s). It is thus suitable for OME-Zarr datasets and easily handles even the huge ones.
From top left to bottom right:
- Open the N5 import dialog at the position of the dropped OME-Zarr. This lists resolution levels found in the OME-Zarr, allowing users to choose one and possibly even crop it and finally open it in the ImageJ window.
- Open the N5 viewer dialog at the position of the dropped OME-Zarr. This also lists resolution levels found in the OME-Zarr, allowing users to choose one or the full pyramid and have it opened in the BigDataViewer.
- Directly open a single-resolution image in ImageJ, which best matches the preferred width in the user settings.
- Directly Open multi-resolution image in BigDataViewer.
- Run a pre-defined script (e.g., a macro) while passing to it the path to the dropped OME-Zarr. This way, the user can define her own action.
- Open a web browser pointing to this Readme file.
- OME-Zarr v0.5 (Zarr v3)
- OME-Zarr v0.4 (Zarr v2)
OME-Zarr v0.3 (Zarr v2)(currently not supported)- Supports 2D (xy) to 5D (xyzct) images, or any subsets of the latter.
- Fiji memorizes the full context of a drag & dropped OME-Zarr. That said, even if the OME-Zarr is opened as a particular resolution in ImageJ via drag & drop, one can still open it in BigDataViewer using all resolution pyramids (via
Plugins -> OME-Zarr ->Plugins > OME-Zarr > Open Current Zarr Image in BigDataViewer). Or the opposite, even if the dropped OME-Zarr has right away landed in BigDataViewer, it is possible to display a particular resolution of it as Dataset in ImageJ.(not yet supported)- To sum it up, once OME-Zarr is in Fiji, users don't have to drop it again to display it differently. This is a great way to save RAM (memory) on your computer.
- Users can drag & drop a top-level OME-Zarr folder, which contains a multi-resolution dataset. It will be opened as multi-resolution data.
- Drag & dropping a subfolder of the top-level OME-Zarr folder (i.e. single-resolution data) is currently not supported.
- Works only when a multi-resolution OME-Zarr is drag & dropped and opened in BigDataViewer.
- The channel names, colors, and contrast limits and their active/inactive state are automatically extracted from the OME-Zarr metadata, if available. The time point is also automatically set to the time point specified in the metadata, if available.
- The reading of OME-Zarrs is done via the N5 library.
- We plan to also support reading through zarr-java.
- Users can run a script on the OME-Zarr. The script resource can be a file and can be set in the
Plugins -> OME-Zarr -> Preset Drag & Drop User Scriptmenu. - If no script is set, the script editor opens with a default script.
- There are some OME-Zarr example datasets in the image data repository. You can download them from here to your local machine to test the drag & drop.
Enable the the Fiji update site OME-Zarr-PREVIEW in the Help -> Update -> Manage Update Sites:
Check out the repo and compile with:
mvn clean package
and place the resulting .jar file into your Fiji.app/jars folder.
You also need to copy the following .jar files to your Fiji.app/jars folder (and delete the older versions, if they are present):
- n5-4.0.0-alpha-11
- n5-aws-s3-4.4.0-alpha-9
- n5-blosc-2.0.0-alpha-4
- n5-google-cloud-5.2.0-alpha-7
- n5-hdf5-2.3.0-alpha-6
- n5-ij-4.5.0-alpha-7
- n5-imglib2-7.1.0-alpha-7
- n5-universe-2.4.0-alpha-8
- n5-zarr-2.0.0-alpha-7
- n5-zstandard-2.0.0-alpha-4
Beyond that, you need to copy this extra .jar files to your Fiji.app/jars folder:
- n5-viewer_fiji-6.2.0-alpha-5
- s3
- auth
- annotations
- aws-core
- identity-spi
- sdk-core
- utils
- regions
- http-client-spi
- profiles
- retries-spi
- endpoints-spi
- http-auth-spi
- 2025: Moved under this github organization from previous URL https://github.com/xulman/ome-zarr-fiji-ui. Code state is here.
- 2024: Project revamped and based solely on the suite of libs around the N5.
- 2024: OME-NGFF Workflows Hackathon 2024 in Zurich.
- 2024: CZI grant about "OME-Zarr Support for Java/Fiji" landed at CEITEC.
- 2023: Changes in the scijava land towards more generic drag & drop handlers.
- 2022: It started at the "Fiji + NGFF Hackathon" in Prague. Code state is here and version with revived code demo is here.
This is a brief outline of what @xulman would like to have in Fiji so that the usual Fiji pipelines (meaning the standard ImageJ macros, Jython scripts, and even GUI-operated plugins) could work with Zarrs and benefit from their chunk-based nature. It is greatly inspired by his previous work on DataStore, which is essentially a suite of Fiji plugins to manage (create, modify and delete full datasets, read and write images or even their chunks) a http-servered N5 datasets.
So, we basically need a suite of Fiji (in fact scijava) plugins that (are
“headless” and) all of them would take a URI to some NGFF data plus specific
parameters depending on a particular function/purpose of a plugin. Examples are
a query plugin, that tells how many time points are available at a given URI,
or how many channels are available, or a plugin that can read a full image at a
given time point and a given channel from URI etc. Using these, it is easy to
construct e.g. a for-loop over all time points to process an image (at variable
time point and fixed particular channel) one after another. To optimize the
work with a particular URI, a scijava service (we could call it NgffService)
should work in conjunction with these plugins. Note that a scijava service is a
singleton object that lives uninterruptedly within Fiji; it is opened and
closed automatically with Fiji. That way, the commands/plugins are “routed”
through the NgffService, which could implement caching (with time-limited
memory) so that e.q. repetitive queries will need not to inspect/talk to the
URI-pointed place (e.g. folder, or remote resource); only the first query will
be “expensive” in this way. At the heart should be a public Java API —
interfaces. Currently, the first implementation is planned using the
n5 library.
The NgffService should wrap around these interfaces.
The plugins would basically outsource their work to the NgffService,
and they could look roughly like this:
@Plugin(type = Command.class, menuPath = "Plugins>OME-Zarr>Read Image")
public class OmeZarrReadImage implements Command {
@Parameter
NgffService ngff;
@Parameter
String URI;
/* More params specifying which image to read in particular */
@Parameter(type = ItemIO.OUTPUT)
Dataset ds;
@Override
public void run() {
Img<?> img = ngff.read(URI, /* params */);
//create 'ds' around the obtained 'img'
//plus the usual 'try-catch', you know ;-)
}
}
Such plugins are directly available via Fiji menus, are (or can be made)
macro recordable, accessible in the standard ImageJ macros and Jython scripts;
the NgffService can be also directly accessible in the Jython scripts. In
fact, these are cheap “side-effects” of the great scijava universe.
The first version is expected to be delivered in 2025.