[ome-users] BioFormats (5.0.2) can't handle very large NDPI files

[Melissa Linkert]

Hi Kristian,

> I have a few very large (>4GB) NDPI files from a HAMAMATSU scanner.
> The scanned slides are sometimes very large (like blood smears) and
> scanned in three or five layers.
> 
> In BioFormats 5.0.2 with bftools, running "showinf -nopix 65.ndpi", I get

*snip*

> The problem seems to be related to integer overflow. I think,
> however, that a solution isn't as simple as changing ints to longs
> (I tried, didn't work).
> 
> I have five sample files at http://micro.sdu.dk/media/bioformats -
> 66.ndpi and 67.ndpi works; 65.ndpi, 68.ndpi, and 69.ndpi don't work.

Thank you for reporting this problem.  The issue definitely does have to
do with file size - anything larger than 4GB will not be readable as
.ndpi files do not follow the BigTIFF specification.  I have filed a
ticket for this on our issue tracking system:

http://trac.openmicroscopy.org.uk/ome/ticket/12367

and would expect this to be working in the next release.

Regards,
-Melissa

On Wed, Jun 04, 2014 at 11:17:11AM +0200, Kristian Kjærgaard wrote:
> Dear fellow users
> 
> I have a few very large (>4GB) NDPI files from a HAMAMATSU scanner.
> The scanned slides are sometimes very large (like blood smears) and
> scanned in three or five layers.
> 
> In BioFormats 5.0.2 with bftools, running "showinf -nopix 65.ndpi", I get
> 
> Checking file format [Hamamatsu NDPI]
> Initializing reader
> NDPIReader initializing 65.ndpi
> Reading IFDs
> Populating metadata
> Exception in thread "main" java.lang.IllegalArgumentException:
> Negative position
>         at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:675)
>         at loci.common.NIOByteBufferProvider.allocateDirect(NIOByteBufferProvider.java:131)
>         at loci.common.NIOByteBufferProvider.allocate(NIOByteBufferProvider.java:116)
>         at loci.common.NIOFileHandle.buffer(NIOFileHandle.java:551)
>         at loci.common.NIOFileHandle.seek(NIOFileHandle.java:273)
>         at loci.common.RandomAccessInputStream.seek(RandomAccessInputStream.java:154)
>         at loci.formats.tiff.TiffParser.getIFDValue(TiffParser.java:479)
>         at loci.formats.tiff.TiffParser.fillInIFD(TiffParser.java:460)
>         at loci.formats.in.MinimalTiffReader.initFile(MinimalTiffReader.java:451)
>         at loci.formats.in.BaseTiffReader.initFile(BaseTiffReader.java:540)
>         at loci.formats.in.NDPIReader.initFile(NDPIReader.java:269)
>         at loci.formats.FormatReader.setId(FormatReader.java:1315)
>         at loci.formats.ImageReader.setId(ImageReader.java:753)
>         at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:569)
>         at loci.formats.tools.ImageInfo.testRead(ImageInfo.java:992)
>         at loci.formats.tools.ImageInfo.main(ImageInfo.java:1074)
> 
> The problem seems to be related to integer overflow. I think,
> however, that a solution isn't as simple as changing ints to longs
> (I tried, didn't work).
> 
> I have five sample files at http://micro.sdu.dk/media/bioformats -
> 66.ndpi and 67.ndpi works; 65.ndpi, 68.ndpi, and 69.ndpi don't work.
> 
> I may be able to provide more samples if needed.
> 
> - Kristian Kjærgaard, BSc.med, happy user of BioFormats
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users