Multi-channel OME-Zarr loading

[constantinpape]

No description provided.

[constantinpape]

Hey @tibuch,
I opened the PR so we can discuss along the code. I noticed 2 things, first is trivial in one of the conditions, but the second seems more important, since it looks to me like the dimensions passed to the view setup changed (and the new code makes more sense to me, but since it worked with the old one I am not sure if the change is correct.)

[constantinpape]

I don't think we need the zarrAxes.is2D here, since this will always have zarrAxes.hasChannels(): false

[constantinpape]

I am a bit confused by the code we had here before; it looks like beforehand we always just put the dimensions from the zarr directly, which might be 2 - 5D. Now we always put a 3D shape. The new code seems more reasonable to me, but it has worked in the old version, so I am not sure if this change is correct.
cc @KateMoreva

[KateMoreva]

But what if we have zarrAxes.hasChannels() == false?

[constantinpape]

Yeah, that's another good point, I think this is missing from above.
@KateMoreva for zarrAxes.hasChannels == false we have the same behaviour as before, see also my comment above.
But what confuses me is that for zarrAxes.hasChannels == true, we now have a different behaviour (before we had the full dimensions, now we only have the spatial ones.)

[constantinpape]

Yeah, that's another good point, I think this is missing from above.
@KateMoreva for zarrAxes.hasChannels == false we have the same behaviour as before, see also my comment above.
But what confuses me is that for zarrAxes.hasChannels == true, we now have a different behaviour (before we had the full dimensions, now we only have the spatial ones.)

[constantinpape]

If zarrAxes.hasChannels() == false we will not go into this branch, won't hit any of the returns and just fall back to the 'normal' return in line 442 (so the same behaviour as before)

[constantinpape]

cc @KateMoreva

[tischi]

@KateMoreva do we already have a Test for loading a multi-channel OME-Zarr image, where we check the values of some pixels in the channels?

[tischi]

I checked out this PR and also here I am getting:

java.lang.UnsupportedOperationException: Could not find multiscales at service endpoint: https://s3.embl.de; bucket: i2k-2020; container path: ngff-example-data/v0.4/czyx.ome.zarr; path: ; attribute: multiscales
    at org.embl.mobie.io.ome.zarr.loaders.N5OMEZarrImageLoader.getMultiscale(N5OMEZarrImageLoader.java:295)

for https://s3.embl.de/i2k-2020/ngff-example-data/v0.4/czyx.ome.zarr

[tischi]

@constantinpape @tibuch
this branch is working for me for this image:
https://s3.embl.de/i2k-2020/ngff-example-data/v0.4/czyx.ome.zarr
I also wrote a function to automatically determine the min and max for all the channels. In this case it returns for me for the lowest resolution:

setup=0
min=0.0
max=5115.0
setup=1
min=0.0
max=280.0

Is that correct?

[tischi]

Trying this with https://s3.embl.de/i2k-2020/spatial-transcriptomics-example/pos42/images/ome-zarr/MMStack_Pos42.ome.zarr
I am getting:

java.lang.ClassCastException: net.imglib2.img.basictypeaccess.volatiles.array.VolatileDoubleArray cannot be cast to net.imglib2.img.basictypeaccess.ShortAccess

	at net.imglib2.type.numeric.integer.GenericShortType.updateContainer(GenericShortType.java:104)
	at net.imglib2.img.cell.CellRandomAccess.updatePosition(CellRandomAccess.java:487)
	at net.imglib2.img.cell.CellRandomAccess.<init>(CellRandomAccess.java:136)
	at net.imglib2.img.cell.AbstractCellImg.randomAccess(AbstractCellImg.java:104)
	at net.imglib2.img.cell.AbstractCellImg.randomAccess(AbstractCellImg.java:51)
	at net.imglib2.util.Util.getTypeFromInterval(Util.java:806)
	at net.imglib2.view.Views.iterable(Views.java:777)

What data type should that be?
Maybe something we don't support yet?

[tischi]

@constantinpape which data type should the image above have (i.e. when you open it in python)?

[constantinpape]

@constantinpape which data type should the image above have (i.e. when you open it in python)?

uint16

[tischi]

TBH, the error does not sounds like it is related to the multi-channel...
Would it be possible to also upload a single channel version of this data, just to check that that works?

[constantinpape]

Here's a version with just one channel: /g/kreshuk/pape/Work/playground/mobie-projects/spatial-trans/test.ome.zarr

[tischi]

As expected, same error.
Something's wrong with identifying the data type in that file.
Maybe create a new issue for that?!

[constantinpape]

I created #107 about this.

[constantinpape]

Ok, turns out there were issues with the data; after fixing them (see #107 for details) everything works as expected on MoBIE-beta now:

(Loading https://s3.embl.de/i2k-2020/spatial-transcriptomics-example)

[tischi]

Could we close this PR?
I added @tibuch such that he also can have a branch here if needed.
I think this will be easier to manage.
I am currently working on this branch: https://github.com/mobie/mobie-io/tree/multi-channel-fix
Not sure whether there are significant differences to the fmi-faim:develop...?!

[constantinpape]

I added @tibuch such that he also can have a branch here if needed.
I think this will be easier to manage.

Sure, that also works. (Though in general it's a good idea to learn how to work with forks, it's not really more difficult ;)).

I am currently working on this branch: https://github.com/mobie/mobie-io/tree/multi-channel-fix
Not sure whether there are significant differences to the fmi-faim:develop...?!

Here's the diff between the two branches: fmi-faim/mobie-io@develop...mobie:mobie-io:multi-channel-fix. So I think we can safely close this PR and continue working from your multi-channel-fix branch since it contains just a few additional commits.