imread_multi() returns 1 image of 3997

[thouis]

I'm unsure what's wrong with this image, but imread.imread_multi() only returns one image. (As do several other python tiff wrappers).

https://drive.google.com/file/d/0Bx-14WwcXFgebmlLUGYwV1ZUc0E/view?usp=sharing

Sorry for the large size; I couldn't create a smaller test case.

tiffinfo reports:
TIFF Directory at offset 0x8 (8)
Subfile Type: (0 = 0x0)
Image Width: 1024 Image Length: 544
Resolution: 0.307669, 0.307669 (unitless)
Bits/Sample: 16
Compression Scheme: None
Photometric Interpretation: min-is-black
Samples/Pixel: 1
Rows/Strip: 544
Planar Configuration: single image plane
ImageDescription: ImageJ=1.47u
images=3997
frames=3997
unit=micron
finterval=0.10010010004043579
loop=false
min=1037.0
max=2281.0

[luispedro]

Wow, that's a pretty large image.

I'll have a look, though.

Does ImageJ load it as you expect?

Luis

[thouis]

Yes.
On Oct 24, 2014 3:22 AM, "Luis Pedro Coelho" [email protected]
wrote:

Wow, that's a pretty large image.

I'll have a look, though.

Does ImageJ load it as you expect?

Luis

—
Reply to this email directly or view it on GitHub
#19 (comment).

[cgohlke]

The file does not really conform to the Tiff standard: First,it contains only one, the first, IFD/page. Second, it is larger than 4 GB but not a BigTiff file (I guess that is why other IFDs could not be appended to the file).
Standard conform tiff readers will only be able to access the first image.
Specialized ImageJ readers only read the first IDF and the ImageJ metadata and then access the contiguous data directly...

[cgohlke]

See also https://github.com/imagej/imagej1/blob/master/ij/io/TiffEncoder.java#L146

[luispedro]

@cgohlke Thanks for the analysis.

ImageJ is annoying in making up its own formats and not even documenting them (I've spent a lot of time reading its source to figure out how it encodes hyperstack metadata).

I'm going to consider this issue as a feature request (support ImageJ TIFFs) and not a bug.

[thouis]

OK. Thanks for looking into it.