Bug in the Writing ImageJ compatible metadata example

[lanceXwq]

Hello,

I was going over the Writing ImageJ compatible metadata example and noticed a bug may exist. After running this example, ImageJ seemed to misinterpret the produced tiff file. Specifically, although this example should create an "imagej.tiff" with only zeros, I got nonzero pixel values at some slices and frames in ImageJ, as shown in the screenshot below (also see the "Pixel value range" field in the second screenshot).

Moreover, running TiffImage.load("imagej.tiff") still produces an all-zero image stack.

I am using Julia 1.11.3, TiffImages 0.11.3, ImageJ 1.54p (see below).

Please let me know if you need any more info. I appreciate any help you can provide!

[lanceXwq]

Upon a second look, I noticed that this could actually be ImageJ's issue. None of Icy, Ubuntu's document viewer, or Bio-Formats Importer shares the same problem. I will close this issue for now.

[cgohlke]

See https://forum.image.sc/t/tiff-file-read-incorrectly/109208

[lanceXwq]

I am reopening this issue for the reason @cgohlke stated in the link posted above. For the sake of convenience, I am posting it here.

While the file is (almost) valid TIFF, it is not a valid ImageJ TIFF. When ImageJ encounters a ImageDescription tag value in the first IFD starting with “ImageJ”, it stops reading other IFDs and instead assumes that all image data are contiguously stored at an offset specified in the StripOffsets tag. In this TIFF file, the image stack is stored non-contiguously. For larger stacks, ImageJ requires that IFD tags are written before the contiguous image data, which is not the case here either.

[tlnagy]

Hi @lanceXwq, thanks for the bug report and sorry that the demo was overly primitive. The original impetus behind the demo was trying to showcase TiffImages.jl's API for manipulating IFD data.

It appears from @cgohlke's comment that ImageJ is less flexible than I was expecting when I wrote this short demo. It would be quite easy to modify TiffImages.jl's writer to write the IFDs first when saving ImageJ compatible TIFFs. Honestly, this complexity shouldn't be exposed to the user at all and use something like tifffile's imagej flag, see #135 for a bit of the thinking there.

[tlnagy]

The one commenter who brought up the exiftool -validate -a -warning has a point. It's clear from the output that this demo falls short:

Validate                        : 49 Warnings (36 minor)
....snip.....
Warning                         : [minor] Odd offset for IFD11 tag 0x011a XResolution
Warning                         : [minor] Odd offset for IFD11 tag 0x011b YResolution
Warning                         : Non-standard format (int8u) for IFD11 0x0128 ResolutionUnit
Warning                         : [minor] Odd offset for IFD11 tag 0x0131 Software
Warning                         : Missing required TIFF IFD0 tag 0x0116 RowsPerStrip

Looks like the primary issues are with odd offsets in this demo. I'm not actually sure what exiftool means with this, but I'm guessing it has something to do with the bit packing.

[juliohm]

It would be quite easy to modify TiffImages.jl's writer to write the IFDs first

That would be very useful @tlnagy. If IFDs are written first, we are one step closer from what people call cloud-optimized geotiff (COG). GeoTIFF.jl would directly benefit from this change.