Sparse tiles in output from CZI scans

[PresageMicah]

Background

I'm attempting to use ASHLAR 1.15.2 on a couple Zeiss (CZI) 5-channel whole slide images. However, the results are showing strange tiling issues, basically sparse tiles with no data in between. I'd love some advice to troubleshoot this issue, or, if this is due to a bug in ASHLAR, I'm happy to help investigate.

Also, while running ASHLAR, I received some warnings ("WARNING: Stage coordinates' measurement unit is undefined; assuming μm."), and I'm wondering if that's the issue, and if there is a workaround. I'd also appreciate any additional explanations about those warnings. Full console output below.

Image output

Here's the zoomed-out output from running two whole slide images (screen clip is from Fiji, which can barely handle this gigantic image):

And here I'm using much smaller exported ROIs from the same images (screen clip is from ZEN, blue for the first image's DAPI channel and red for the second image's DAPI channel, though all channels from each image are contained within those respective rectangles):

Console output

Here's the full console output of my ASHLAR run on the exported ROIs that yielded the second image above. Both images have 5 channels and their last channel is DAPI, so I entered --align-channel 4 to reference that DAPI channel using ASHLAR's 0-based indexing.

D:\ashlar\output2>ashlar "c:\temp\ashlar\data\4420-cropped.czi" "c:\temp\ashlar\data\4610-cropped.czi" --align-channel 4
Stitching and registering input images
Cycle 0:
reading c:\temp\ashlar\data\4420-cropped.czi
WARNING: Stage coordinates' measurement unit is undefined; assuming μm.
assembling thumbnail 12/12
quantifying alignment error 1000/1000
aligning edge 3/3
Cycle 1:
reading c:\temp\ashlar\data\4610-cropped.czi
WARNING: Stage coordinates' measurement unit is undefined; assuming μm.
assembling thumbnail 12/12
estimated cycle offset [y x] = [-97.6009913 -95.       ]
aligning tile 12/12

Merging tiles and writing to ashlar-output.ome.tif
Cycle 0:
Channel 0:
merging tile 12/12
Channel 1:
merging tile 12/12
Channel 2:
merging tile 12/12
Channel 3:
merging tile 12/12
Channel 4:
merging tile 12/12
Cycle 1:
Channel 0:
merging tile 12/12
Channel 1:
merging tile 12/12
Channel 2:
merging tile 12/12
Channel 3:
merging tile 12/12
Channel 4:
merging tile 12/12
Generating pyramid
Level 1 (8229 x 7367)
processing channel 10/10
Level 2 (4115 x 3684)
processing channel 10/10
Level 3 (2058 x 1842)
processing channel 10/10
Level 4 (1029 x 921)
processing channel 10/10
Level 5 (515 x 461)
processing channel 10/10

Thanks for any assistance on this matter. I'm just taking off on vacation so I won't be able to get to responses right away, but I'll follow up on Monday, May 23rd.

[Yu-AnChen]

Thanks @PresageMicah for the detailed description - in our past experiences with CZI files, we needed to add the --flip-y flag to the ashlar call as different vendors place the origin of stage coordinate differently.

[PresageMicah]

--flip-y flag

Thanks @Yu-AnChen for the quick response! I re-ran it with that flag and got the same problem, though I can see that the pattern is slightly different:

[Yu-AnChen]

Thanks for the quick check. The other two parameters I would suggest trying are --filter-sigma 1 and -m 30 in addition to the --flip-y. For testing, you could have ashlar output only the DAPI channels, for example --output-channels 4

To put it all together

ashlar "c:\temp\ashlar\data\4420-cropped.czi" "c:\temp\ashlar\data\4610-cropped.czi" --align-channel 4 --output-channels 4 --flip-y --filter-sigma 1 -m 30

This closed issue (#92) is relevant.

[Yu-AnChen]

Another possibility could be that there's a bug in reading pixel data through BioFormats - if you're able to share the CZI files with us (maybe send the download link to my or @jmuhlich's email) we'll inspect them.

[PresageMicah]

Thanks @Yu-AnChen for reviewing our files and providing your insights over email. We're still narrowing it down, but I thought I'd summarize our conversation for anyone else encountering the same issue.

It doesn't seem to be a problem with corruption - every scan from this scanner that I have tested has this problem and they are all viewable in the ZEN viewer.

However, it does seem to be a problem with accessing the raw FOV data from the CZI scans, which ASHLAR needs instead of the autostitched mosaic generated by ZEN. I'm wondering if this is an issue with our particular scanner, or perhaps just our scanner configuration, and I'm reaching out to Zeiss support for more information.