SDT - Handle IllegalArgumentException

[dgault]

This is for an issue raised on the mailing list - http://lists.openmicroscopy.org.uk/pipermail/ome-users/2017-October/006718.html
Associated sample file: QA-18098

The problem is caused by reading the block length of the data block and attempting to skip that number of bytes. The expected result from skip bytes should be that it attempts to skip the number of bytes provided and if the end of the file is reached returns the actual number skipped (eg https://docs.oracle.com/javase/7/docs/api/java/io/RandomAccessFile.html#skipBytes(int)). However NIOFileHandle in common throws an exception.

For compressed data the number of available bytes in the file may be less. We have other sample files of this nature (QA-11079) which similarly attempt to skip a number of bytes which do not exist, by chance these do not throw the same error though. I believe the real fix should be in NIOHandle (likely https://github.com/ome/ome-common-java/blob/43ca478d2977455c79656b12f1ad60aa39f1f86e/src/main/java/loci/common/NIOFileHandle.java#L456) however it could be worthwhile to include a fix at the format level for a patch release.

To test:

• Ensure all builds and tests remain green
• Using QA-18098 and QA-18827, read the files without the PR (using showinf) and you should see an IllegalArgumentException
• With PR redo the above test and ensure that the files are able to be read without exception

[dgault]

A further report of this has been received in QA-18827

The fix originally in place in the PR was not sufficient for these latest sample files. The last commit should enable the correct block headers to be read using the nextBlockOffs, which from the CPP header we have as part of the spec is the offset to the data block header of the next data block.

[mtbc]

Would simply always doing the else branch also work? Just curious as to the logic here.

[mtbc]

I can't see anything coherent in the QA-18098 image but the functional testing does pass in my opinion.

[dgault]

Yeah, unfortunately the files which are causing this issue appear to be from FIFO mode which produces compressed photon data files, as such the actual display does not appear as an easy identifiable image for testing purposes. Instead it displays as single pixels with very low counts.

I shall test removing the else to see if there are any impact on existing data sets.