Failure Loading s3 zarr OME-NGFF on web app (possible windows issue with zarr)

[DippedPretzels]

I generated an ome.zarr file using the example image from ome-zarr-py:
https://gist.github.com/constantinpape/69e3cb8e0401621365d814b4d6fda0bc

However, in Windows 10, the file explorer views this as a folder named "my-first.ome.zarr". The contents of the folder appear to me to be formatted properly, and loading the folder works in ome-zarr-py.

When uploading to s3, I can only upload "my-first.ome.zarr" as a folder, and copying the URL yields "https://....[excluded]...amazonaws.com/my-first.ome.zarr/". This is a public URL, and I followed the instructions on http://vitessce.io/docs/data-hosting/ for setting up the S3 bucket properly. I checked and was able to download contents inside the subfolders just fine.

Then, on vitessce.io, on the examples page, using Blin et al., PLoS Biol 2019, I simply replaced the image URL with mine. When I try to load this image, in status, it claims "Failed to fetch"

I think this may be due to vitessce expecting a url ending in .zarr, and the url I provided ending in .zarr/. I'm not sure how linux recognizes .zarr - a file or folder, but this might be the issue with windows here. I tried uploading in the windows aws cli, and the web interface, and neither supported me uploading the .zarr folder as a file.

[ilan-gold]

Can you share your view config? A url to your data? Or any of the network logs showing exactly how the requests failed?

[DippedPretzels]

Sure - it's just the confocal image example on the page, but I changed the url to mine:
https://lstest1.s3.us-east-2.amazonaws.com/my-first.ome.zarr/
Trying the url without the "/" at the end of .zarr also fails.

Sorry, I don't know how to view the network logs in the web app, just that all the other panes don't load anything, but in the 'Status' pane, it says "Failed to fetch"

{
  "version": "1.0.6",
  "name": "Blin et al., PLoS Biol 2019",
  "description": "Mouse blastocysts imaged by confocal microscopy",
  "public": true,
  "datasets": [
    {
      "uid": "test1",
      "name": "test1",
      "files": [
        {
          "type": "raster",
          "fileType": "raster.ome-zarr",
          "url": "https://lstest1.s3.us-east-2.amazonaws.com/my-first.ome.zarr/"
        }
      ]
    }
  ],
  "initStrategy": "auto",
  "layout": [
    {
      "component": "spatial",
      "x": 0,
      "y": 0,
      "w": 8,
      "h": 12
    },
    {
      "component": "layerController",
      "x": 8,
      "y": 0,
      "w": 4,
      "h": 6
    },
    {
      "component": "description",
      "x": 8,
      "y": 6,
      "w": 4,
      "h": 3
    },
    {
      "component": "status",
      "x": 8,
      "y": 9,
      "w": 4,
      "h": 3
    }
  ]
}

[ilan-gold]

There appears to be a CORS error so I think there is something up with the bucket (for future debugging, you can access the browser/web console usually via tools or developer tools depending on your browser):

[DippedPretzels]

Thanks - never really used those developer tools!

It looks like the example s3 CORS on http://vitessce.io/docs/data-hosting/ is missing an additional term in "ExposeHeaders". It needs to have "Access-Control-Allow-Origin" in addition to "Content-Range".

After doing that, I no longer get the 'Access-Control-Allow-Origin" error that you linked above. Instead I get "Path for image not valid". Attached are the errors and also the contents of my-first.ome.zarr. In the config, for the url, I again tried ending it in .zarr and .zarr/

[keller-mark]

Hi @DippedPretzels, it looks like this image does not have the omero field in the root .zattrs file.

https://lstest1.s3.us-east-2.amazonaws.com/my-first.ome.zarr/.zattrs vs https://minio-dev.openmicroscopy.org/idr/v0.3/idr0062-blin-nuclearsegmentation/6001240.zarr/.zattrs

Apologies that this is not well documented (and this error message is not very clear), but here in the loader if there is no omero field, the error will be thrown. The omero.channels and omero.rdefs fields provide metadata that vitessce uses for the initial rendering settings.

[DippedPretzels]

@keller-mark Thanks you're right - it didn't have an omero field. The example .zattrs for a czyx is helpful. It looks like the issue I have now is creating a proper czyx .zarr file. Both examples on ome-py-zarr (here) and ngff-writer (here) do not show a case creating a czyx file. ngff-writer, when only 2 .tff z stacks are input, would yield a .zarr with only two sub directories (/0 and /1, my .zarr here). Trying to load this .zarr in the Vitessce actually works with one channel, but obviously fails to load the other.

I know support for czyx data was a fairly recent addition in OME-NGFF, but is there example code of creating one with any of the existing tools (ome-py-zarr, ngff-writer, bio-formats)?

[DippedPretzels]

Here are the error messages in Vitessce when the 2nd channel is trying to load when only 0/ and 1/ subfolders are present (for 2 .tiff Z-stacks).

[keller-mark]

Hi @DippedPretzels

I just realized that there is a new spec for OME-NGFF (v4.0) that changed part of the JSON schema. Until this new version is supported in viv (and then here in Vitessce) you may want to use a previous version of ome-zarr-py that writes v3.0 OME-NGFFs (ome-zarr==0.2.1). An example writing to a zarr store using the axes parameter:

from tifffile import imread
import zarr
from ome_zarr import writer

my_image = imread("my_image.tif")
z_root = zarr.open_group("my_image.zarr", mode = "w")

default_window = {
    "start": 0,
    "min": 0,
    "max": 65_535, # may need to change depending on the numpy dtype of the my_image array
    "end": 65_535 # may need to change depending on the numpy dtype of the my_image array
}

writer.write_image(
    image = my_image,
    group = z_root,
    axes = "czyx",
    omero = {
        "name": "My image",
        "version": "0.3",
        "rdefs": {},
        "channels": [
            {
                "label": f"Channel {i}",
                "color": "FF0000", # may want to change to a different color for each iteration or channel
                "window": default_window
            } for i in range(my_image.shape[0])
        ]
    }
)

[DippedPretzels]

@keller-mark Ah - thanks for all your help on this. After trying your code above on ome-zarr==0.2.1, the result on Vitessce looked goofy. I realized ImageJ spits out merged TIFF files (say 2 channel, 10 z steps, 1024x pixels, 1024y pixels) in ZCXY, so the .zarr file gets created this way, then Vitesse reads it as 10 channels and 2 Z steps. Is there a way around this?

[keller-mark]

One option would be to transpose the axes after reading the image

import numpy as np

my_image = imread("my_image.tif")
my_image = np.transpose(my_image, axes=(1, 0, 3, 2)) # zcxy to czyx

Also you may need to use the chunks argument of write_image

writer.write_image(
    image = my_image,
    # ...,
    chunks=(1, 1, 256, 256)
)

[DippedPretzels]

That worked! Thanks! I did not use the chunks argument.

In the 3D view, the Z-axis looks spaced equally to x and y, so for zxy of 10 x 1024 x 1024, the 3D volume looks squished in the Z axis. Adding new interpolated frames in z fixes this - but I'm trying to figure out how to scale the z so that's not required.

It looks like the 0.4 version of NGFF has some way to define this, bit I can't see how the 0.3 version NGFF scales an axis:
https://ngff.openmicroscopy.org/0.3/index.html

I know Vitessce doesn't yet support downscaling across the Z axis, but at least in the full, undownscaled dataset, I'm not sure how to space out across Z.