Repository navigation
MCQUANT falsely fails "channels don't match" on large images #163
Description
Description of the bug
On large stitched images, MCQUANT fails with:
Exception: The number of channels in markers.csv doesn't match the image
…even when the markers and the image genuinely have the same number of channels (in our case markers.csv = 44 rows and the image's OME SizeC = 44). Small images (e.g. the exemplars) are always fine — it only shows up on large, multi-sample runs, and each failing attempt spends ~15 min before erroring.
The cause is in n_channels() (mcquant/SingleCellDataExtraction.py): the channel count is derived from min(tifffile.TiffFile(image).series[0].shape), which requires parsing the full IFD chain of a multi-GB pyramidal OME-TIFF. On AWS Batch (no Fusion) the image is copied to local scratch before the task runs, and under concurrent multi-sample execution that copy can come back incomplete (scratch/throughput contention, no integrity check). tifffile then can't walk the full directory and returns a 2-D shape, so n_channels returns 1 → the check fails. It's a false negative caused by reading the pixel payload instead of the metadata.
Fix would be to read the channel count from the OME-XML SizeC rather than from min(series[0].shape) — it lives at the tail of the file, is cheap, and doesn't depend on a fully-staged/parseable pixel payload. (Optionally also validate the staged input, and/or let this exception be retried.)
Command used and terminal output
Relevant files
No response
System information
No response
Activity