imread
imread copied to clipboard
luispedro
imread_multi() returns 1 image of 3997
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
Wow, that's a pretty large image.
I'll have a look, though.
Does ImageJ load it as you expect?
Luis
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 https://github.com/luispedro/imread/issues/19#issuecomment-60352984.
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...
See also https://github.com/imagej/imagej1/blob/master/ij/io/TiffEncoder.java#L146
@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.