Unknown tags reading tiff

1

I have received a 3D tiff file that gives me warnings about unknown tags when I try to read it with ImageFileReader in ITK 4.12.2. The unknown tags are: 50838, 50839. The execution is stopped with no other information provided. This is on a Win7 machine. Interestingly, the file is read successfully with the same program on a Win10 machine, built with ITK 4.7.2. The tag warnings are the same, but execution continues.
In each case ITK is built 64-bit. The tiff file is about 2.05 GB.

What can cause a read to work on Win10 but not on Win7?

Edit: It seems that the Win10 program is not really working properly, although it does not crash. The program simply compresses a tiff - reads in the file then writes it with compression. The original tiff has 861 pages, but according to Iranview64 and Windows Photo Viewer the compressed file has only 21 pages when using Packbits or LZW, and only 4 pages when using Zip/Deflate! The pages that can be displayed are correct, but the sizes of the compressed files are obviously inconsistent with the number of pages - the Packbits and LZW files are about 1.8 GB. I guess those unknown tags must be doing something important.

2

I don’t know how to help with the ImageFileReader terminating, but I do know what those tags are: they are from ImageJ 1.x.

The Pillow library faced a similar problem and added support for them; see python-pillow/Pillow#291.

This lengthy discussion of ImageJ TIFF files might be useful for further understanding of this format.

One workaround you could try is the SCIFIO ImageIO plugin, which leans on Bio-Formats and should be able to read this flavor of TIFF successfully.

1 Like
3

That makes sense - my collaborator used ImageJ/Fiji to make the stack of 2D tiffs into a 3D tiff. I am planning to reconstruct the 3D tiff myself. Thanks!

1 Like
4

Were where just talking about these tags in an ITK issue:

1 Like
5

Hi Bradley,
It seems that those tags were inserted by ImageJ. There were other issues with that 3D image file (by-slice scaling was used converting from 16-bit to 8-bit), and I have now reconstructed it from the 2D slices using ITK code.
Not strictly relevant, but I am disappointed to find that the new 64-bit version of Irfanview still can’t handle files bigger than 2 GB - at least, not a big file that I create.
Gib

6

I wonder if anybody here knows more about Irfanview64. I can see that the problem is not with the image size as such - I can view an example 8 GB .png image. The 2D slices that make up my 3D tiff are 8-bit (grayscale) 1807x1495. A 3D image made from 790 is just less than 2GB, and when viewed in Irfanview64 shows as having 790 pages, all viewable. When it is made with 816 slices the size is just greater than 2GB, and although Irfanview64 can load it without error, only 2 pages can be viewed. Apparently when the 2GB size threshold is crossed Irfanview64 cannot correctly interpret the page indexing info written by ITK’s imageFileWriter. Is the fault with ITK or with Irfanview?

7

Try to load the same .tif file in ITK-SNAP and 3D Slicer. If they display the file correctly, the problem is in IrfanView. Otherwise the problem is in ITK.

8

Thanks Dzenan. I can open a big tiff created with ITK software in ITK-SNAP, and see all the pages. Interesting version 3.6 still doesn’t have Tiff as one of the File Formats in the GUI, but a tiff file can be opened from the command line. So it appears that Irfanview is deficient - surprising, since it is such a good tool.