VolocityReader ArithmeticException (divide by zero)

Hi there!

We’re currently running into trouble with some specific mvd2 files - for most of them, importing them into OMERO works fine, but some of them fail with the current error:

java.lang.ArithmeticException: / by zero
	at loci.formats.in.VolocityReader.initFile(VolocityReader.java:624) ~[formats-gpl.jar:5.9.2]
	at loci.formats.FormatReader.setId(FormatReader.java:1397) ~[formats-api.jar:5.9.2]
	at loci.formats.ImageReader.setId(ImageReader.java:842) ~[formats-api.jar:5.9.2]
	at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:650) ~[formats-api.jar:5.9.2]
	at loci.formats.ChannelFiller.setId(ChannelFiller.java:223) ~[formats-bsd.jar:5.9.2]
	at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:650) ~[formats-api.jar:5.9.2]
	at loci.formats.ChannelSeparator.setId(ChannelSeparator.java:291) ~[formats-bsd.jar:5.9.2]
	at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:650) ~[formats-api.jar:5.9.2]
	at loci.formats.Memoizer.setId(Memoizer.java:662) ~[formats-bsd.jar:5.9.2]

Running OMERO 5.4.9 (with Bioformats 5.9.2). We can’t figure out what is different about these files. I’ve looked around here and in the OME forums for similar problems, without success. Are we doing anything wrong is this a Bio-formats issue?

Thanks in advance!

This looks like a Bio-Formats bug caused by it thinking size T or size Z is 0 . Would you be able to upload one of the failing faile to https://www.openmicroscopy.org/qa2/qa/upload/ for testing?

Uploaded as faulty_mvd.zip. Thanks!

Thanks @erickratamero, I have been able to test and reproduce the issue as described.
The issue appears to be caused by the parsing of the timepoints file 75.atsf. All of the other timepoint files are parsed as having 1 timepoint which is 3.635333939842001E9, but this file is parsed to return the number of timepoints as 0. Is there any reason that this file would be different from the rest?

Not that I’m aware - the user who captured those images did not report any other issues. Also, this is not the only mvd2 that presented this issue, so it’s definitely not a one-off.

Quick update: opening the relevant files in Volocity shows that one or more captures seem to be corrupted indeed (and trying to open one of the corrupted captures crashes Volocity with a similar “number of timepoints is 0” error). Deleting the corrupted captures seem to restore intended behaviour and files can be opened using Bioformats again.

We’ll try and figure out what has caused these files to be saved like that, but I don’t think it’s a Bioformats issue. Thanks again for the support!