I'm trying to lazy-read a folder containing multiple 2D .ome.tif files into a 3D (x,y,z) stack with dask and run into this issue.
The problem seems to be that during the loading of a single 2D image, tifffile.imread reads the OME metadata which describes the entire dataset, not just a specific 2D image.
The problem goes away by lying to tifffile and forcing it to ignore the OME-specific metadata with tifffile.imread(file_path, is_ome=False).
In the read_with_dask function this could be implemented by simply modifying the call to lazy_imread:
lazy_arrays = [lazy_imread(fn, is_ome=False) for fn in get_sorted_file_paths(filenames)]
I've verified locally that the above patch solves the problem.
Since the issue is with tifffile, I'm not sure whether we want to implement this workaround here. The only immediate benefit of doing so would be my and @alessandrofelder's convenience (collaborators have shared with us lots of data in .ome.tif format and it would be nice to be able to use brainglobe-utils for loading it).
An alternative would be to implement proper OME-aware loading of such stacks.
I'm trying to lazy-read a folder containing multiple 2D .ome.tif files into a 3D (x,y,z) stack with dask and run into this issue. The problem seems to be that during the loading of a single 2D image,
tifffile.imread
reads the OME metadata which describes the entire dataset, not just a specific 2D image.The problem goes away by lying to
tifffile
and forcing it to ignore the OME-specific metadata withtifffile.imread(file_path, is_ome=False)
.In the
read_with_dask
function this could be implemented by simply modifying the call tolazy_imread
:I've verified locally that the above patch solves the problem.
Since the issue is with
tifffile
, I'm not sure whether we want to implement this workaround here. The only immediate benefit of doing so would be my and @alessandrofelder's convenience (collaborators have shared with us lots of data in .ome.tif format and it would be nice to be able to usebrainglobe-utils
for loading it).An alternative would be to implement proper OME-aware loading of such stacks.