Support 2D-only OME-Zarrs? #398
Comments
|
This is actually an example of hitting this issue here: #150 The issue arises primarily because we have 3D ROIs & 2D images. But even if our ROIs would be 2D as well (=> the indexing would work if we also handle that case), the cellpose function would still always return a 3D output image (the way it's currently programmed) and we have some other 3D assumptions in its code. 2 takeaways:
To attempt 2: |
|
How would one of the 2D-only input OME-Zarrs that we'd like to support look like? Would it be fully CYX like the one below? I'm trying to write a test with this kind of input, but I'm not sure this was your intended goal @jluethi, nor I'm sure that #403 is enough (I'm still reviewing..). 'multiscales': [
{
'axes': [ ############### NOTE: There is no Z
{
'name': 'c',
'type': 'channel',
},
{
'name': 'y',
'type': 'space',
'unit': 'micrometer',
},
{
'name': 'x',
'type': 'space',
'unit': 'micrometer',
},
],
'datasets': [
{
'coordinateTransformations': [
{
'scale': [ ############## NOTE: CYX
1.0,
0.1625,
0.1625,
],
'type': 'scale',
},
],
'path': '0',
},
{
'coordinateTransformations': [
{
'scale': [
1.0,
0.325,
0.325,
],
'type': 'scale',
},
],
'path': '1',
},
{
'coordinateTransformations': [
{
'scale': [
1.0,
0.65,
0.65,
],
'type': 'scale',
},
],
'path': '2',
},
{
'coordinateTransformations': [
{
'scale': [
1.0,
1.3,
1.3,
],
'type': 'scale',
},
],
'path': '3',
},
{
'coordinateTransformations': [
{
'scale': [
1.0,
2.6,
2.6,
],
'type': 'scale',
},
],
'path': '4',
},
],
'version': '0.4',
},
],
'omero': {
'channels': [
{
'active': True,
'coefficient': 1,
'color': '00FFFF',
'family': 'linear',
'inverted': False,
'label': 'DAPI',
'wavelength_id': 'A01_C01',
'window': {
'end': 800,
'max': 65535,
'min': 0,
'start': 110,
},
},
],
'id': 1,
'name': 'TBD',
'version': '0.4',
},
} |
I'm still not convinced that #403 would not work for this kind of OME-Zarr input. In fact it may be that it does, by accident, by interpreting the C dimension as a Z dimension - when parsing the ZYX pixel sizes (via |
|
With bad56c4, I added a test that runs the Cellpose task on a true CZY OME-Zarr array. The test actually passes, and it produces labels, but I think this is again not working correctly. where it's clear that the |
|
As of our discussion a few minutes ago:
|
|
Great overview of conclusions from the call, this should be the scope limit for merging it.
Yes, the examples I have so far always are like this and I'm aiming for supporting CYX support, not YX support. Yes, that this works is somewhat accidental, we'll need to improve with #150 eventually.
If we include a check for the presence of a C axis in relevant library functions, then that should be save and show us where we'd need to continue when we get back to it. |
|
|
The new
|
|
That's great! 👏🏻 |
I've not run example 01 in fractal-demos (as of fractal-analytics-platform/fractal-demos@1152116), and it went through with no noticeable issues.
|
|
That's great! Sounds like we're ready to merge this then. |
See 09f0c8d |
|
I also ran example 01 locally now and all looks good to me there. I'll continue work to update the MD converter task for server 1.3.0 & tasks 0.10.0 compatibility and will test that afterwards, but would open new issues and a new PR if problems come up there. |
When we have a CZYX OME-Zarr and we call Both TL;DR Even if we don't have much flexibility, in the current (transitional..) state of fractal-tasks-core, I don't see any special issue with MIP in current workflows:
|
There's nothing left on my side re: #403. |
Add 2D support for Cellpose & napari workflows task (closes #398)
github-project-automation
bot
moved this from TODO
to Done
in Fractal Project Management
We save our 2D OME-Zarrs as (z, y, x) images with (1, size_y, size_x). Some other OME-Zarrs (e.g. the ones generated by the faim-hcs OME-Zarr converter) can be (x,y) only, i.e. (size_y, size_x).
This then leads to issues in our processing, for example the following error in cellpose. The problem here is a mismatch between ROI dimensions (ROIs always being z, y, x) and image dimensions.
TODO: Figure out whether we can support 2D OME-Zarr images
I'd prefer 1, but need to evaluate
The text was updated successfully, but these errors were encountered: