Handling ome-zarr files

[Rdornier]

Hi @AlbertDominguez

I'm trying to use spotiflow with ome-zarr files as input but it is apparently not supported yet, as I get this error

INFO: Spotiflow: ValueError: No valid image files found in directory \spotiflow-temp\SPOT_5003_1561_283_118_0_ome.zarr. Allowed extensions are: ('tif', 'tiff', 'png', 'jpg', 'jpeg')

I used this command in the CLI

spotiflow-predict.exe spotiflow-temp\SPOT_5003_1561_283_118_0_ome.zarr --out-dir spotiflow-temp --verbose --device cpu

The ome-zarr files are generated using the OMEZarr exporter of QuPath 0.6.0. They are following OME-Zarr 0.4 specs (OME-Zarr 0.5 are not yet implemented in QuPath).

Here is a sample file of ome-tiff (working) and the same region in ome-zarr format.

Do you think it could be possible to integrate the reading of ome-zarr files in spotiflow ?

Rémy.

[AlbertDominguez]

Hi @Rdornier

Thanks for all the info! I've enabled the option to predict on ome-zarr inputs in the last commit in the main branch. You nevertheless would need to add an extra parameter in the call to the spotiflow-predict CLI to pass the zarr component that one wants to predict on, in your case s0:

spotiflow-predict /path/to/img.ome.zarr --zarr-component s0 # ...

Seems to work perfectly for me on your sample ome-zarr! Would you mind testing it from a local installation to make sure it runs smoothly in your QuPath extension before I release? Basically pip install git+https://github.com/weigertlab/spotiflow.git in your conda env should do

PS: for now in the CLI, the whole OME-Zarr is loaded in-memory and processed normally. Although Spotiflow can handle out-of-memory computation too, it's a bit trickier to automatize everything in a CLI from the user perspective, so I need to think about it a bit more deeply to implement it. I'll get back once I have some bandwidth and have figured that out :)

[Rdornier]

Hi @AlbertDominguez

Thanks you very much for the quick solution.
I tested it within QuPath and it works perfectly as well

for now in the CLI, the whole OME-Zarr is loaded in-memory and processed normally. Although Spotiflow can handle out-of-memory computation too, it's a bit trickier to automatize everything in a CLI from the user perspective, so I need to think about it a bit more deeply to implement it. I'll get back once I have some bandwidth and have figured that out :)

Ok, sounds good

[Rdornier]

Hi @AlbertDominguez ,

Do you know when the ome-zarr handling will be released in a stable version ?
Thanks,

Rémy.

[AlbertDominguez]

Hi @Rdornier,
I've just released a new stable version, 0.5.8. It includes the ome-zarr prediction in the CLI. I'll leave the issue open for now so to improve the automatization in future versions 🙂

[Rdornier]

Hi @AlbertDominguez , Thanks for the release !

[AlbertDominguez]

Hi @Rdornier, some updates about this! I've added a new CLI argument (--zarr-component-lowres) in the latest release (0.6.x) which basically is used to compute the normalization values on, which should speed up things substantially for large inputs.
The idea is that the intensity percentiles should be computable from a lower resolution version of the input with little impact on the prediction if the input is large enough. This will only be used if enough memory (2x the image size as a rule of thumb) is available, otherwise it will fall back to computing the normalization values on the full resolution by blocks, which is the current behaviour.
It will not affect the QuPath extension if you do not use the new argument, but just to let you know in case you want to fiddle around to see if you can get some runtime boost 🙂

[Rdornier]

Hi @AlbertDominguez

Thanks for the update ! Sounds like a very good news. I'll integrate it in the QuPath extension for sure !

[Rdornier]

One thing : --zarr-component-low-res is not recognized as a valid argument ; I think it's this argument --zarr-component-lowres that we should use. But it seems that is also wait for another argument. What should I enter after --zarr-component-lowres ? Is it s0, like for --zarr-component ?
Thanks

[AlbertDominguez]

One thing : --zarr-component-low-res is not recognized as a valid argument ; I think it's this argument --zarr-component-lowres that we should use.

Whoops you're right that was a typo, sorry! I've just edited it.

But it seems that is also wait for another argument. What should I enter after --zarr-component-lowres ? Is it s0, like for --zarr-component ? Thanks

Yes! It should be X or sX (depending on the file), where X would be the pyramid level. E.g. passing --zarr-component-lowres s2 would use the pixel values at the third level to compute the normalization percentiles. If you'd pass --zarr-component-lowres s0 then it'd try to use the highest resolution itself, which might not be too useful.

[Rdornier]

Yes! It should be X or sX (depending on the file), where X would be the pyramid level. E.g. passing --zarr-component-lowres s2

Ok, but what about if s2 doesn't exist ? Do you handle this case or do we have to check which is the lowest resolution level and take this one ? I thought initially that getting the lowest resolution level for this argument was handling by spotiflow but now, I'm not sure; that's why I'm asking.

Thanks

[AlbertDominguez]

But what about if s2 doesn't exist ? Do you handle this case or do we have to check which is the lowest resolution level and take this one ?

As of now passing a resolution level that's not existing would cause the execution to crash with a FileNotFoundError, so it should be checked from the outside when calling the CLI, I'll see if I can automatize this a bit more in the future. Also note that it does not necessarily need to be the smallest resolution (as the information loss may be too large and the normalization percentiles not meaningful), so I think one should pick a pyramid level that contains enough information + does not blow up computationally.

[Rdornier]

Hi @AlbertDominguez

I hope you are doing well.
I tried to use ome-zarr files for training but it turns out that they are not supported for training.
Do you think it's possible to also support this format for training ?

Thanks !
Rémy.

[Rdornier]

Hello @AlbertDominguez

I hope you are doing well.
I have an issue with the OME-Zarr support in spotiflow.

QuPath exports OME-Zarr with the following structure (which is the correct one)

But spotiflow is not happy with this format; it expects the following one (which is not the format output by NGFF converter)

Could you please have a look to this ?

Also, what about handling OME-Zarr for training data (above post) ?

Thanks !
Rémy.

Examples files

• output of QuPath 0.6.0 : currently working in spotiflow 0.6.4

• output of QuPath 0.7.0: not working anymore with spotiflow 0.6.4