TIFF stack correctly being parsed but axis assignment fails.

[zjniu]

I created a TIFF stack using the tifffile package and specifying the axis order using tifffile.imwrite('image.tif', image, metadata={'axes': 'CYX'}). Here is one such TIFF to this issue, which has a total of 4 channels. While the parser successfully detects the channels, as shown below, it fails to assign the axes properly. The size of each axis is displayed as a question mark.

[manthey]

This file contains erroneous information. It has some metadata from tifffile that says it is {"axes": "ZTCYX", "shape": [1, 1, 4, 1000, 1000]}, but it appears to be written as "shape": [1, 1, 1000, 1000, 4]. Moreover, the last value is four BANDS (also called samples), not CHANNELS. tifffile won't read the pixels in the file (even if it was used to write it).

Probably if it had been written tifffile.imwrite('image.tif', image, metadata={'axes': 'YXC'}) it would have been fine.

[manthey]

See girder/large_image#1273 for a change that hardens against this sort of badly written file.

[zjniu]

@manthey The command that you suggested didn't work. The UI thought that the image had 1000 channels.

[manthey]

Can you send a code snippet of what you are doing with tifffile to make the image stack (with numpy zero arrays, for instance)? I find it odd that you have to specify axes manually and then it can't read them back. It makes me think that tifffile is inconsistent or the api is different than you expect.

[zjniu]

This is akin to the original code I had written.

import numpy as np
import tifffile

image = np.zeros((1, 1, 4, 1000, 1000))
tifffile.imwrite('test.tif', image, metadata={'axes': 'ZTCYX'})

[manthey]

Hmm... When I use tifffile to write things out, they end up the expected way (that is, my dimensions and axes correspond -- as you note, my example would have produced 1000 channels). I can't make a tiff file that is broken in the manner that you shared. Your tiff file had some interesting properties (tifftools dump is shown below), such as white points and chromacities. Are you using some other library to facilitate writing these? Even overriding the photometric and planar arrangement still gets me good files (not like yours).

-- 2023_05_23_pw020_ctrl_well1.tif --
Header: 0x4949 <little-endian> <ClassicTIFF>
Directory 0: offset 8000008 (0x7a1208)
  ImageWidth 256 (0x100) SHORT: 1000
  ImageLength 257 (0x101) SHORT: 1000
  BitsPerSample 258 (0x102) SHORT: <4> 16 16 16 16
  Compression 259 (0x103) SHORT: 1 (None 1 (0x1))
  Photometric 262 (0x106) SHORT: 2 (RGB 2 (0x2))
  FillOrder 266 (0x10A) SHORT: 1 (MSBToLSB 1 (0x1))
  ImageDescription 270 (0x10E) ASCII: {"axes": "ZTCYX", "shape": [1, 1, 4, 1000, 1000]}
  StripOffsets 273 (0x111) LONG: <8> 8 1024008 2048008 3072008 4096008 5120008 6144008 7168008
  Orientation 274 (0x112) SHORT: 1 (TopLeft 1 (0x1))
  SamplesPerPixel 277 (0x115) SHORT: 4
  RowsPerStrip 278 (0x116) SHORT: 128
  StripByteCounts 279 (0x117) LONG: <8> 1024000 1024000 1024000 1024000 1024000 1024000 1024000 832000
  XResolution 282 (0x11A) RATIONAL: 1 1 (1)
  YResolution 283 (0x11B) RATIONAL: 1 1 (1)
  PlanarConfig 284 (0x11C) SHORT: 1 (Chunky 1 (0x1))
  Xposition 286 (0x11E) RATIONAL: 0 1 (0)
  Yposition 287 (0x11F) RATIONAL: 0 1 (0)
  ResolutionUnit 296 (0x128) SHORT: 1 (None 1 (0x1))
  PageNumber 297 (0x129) SHORT: <2> 0 1
  WhitePoint 318 (0x13E) RATIONAL: <2> 10492471 33554432 (0.3127) 689963 2097152 (0.329)
  PrimaryChromaticities 319 (0x13F) RATIONAL: <6> 5368709 8388608 (0.63999999) 11072963 33554432 (0.33000001) 5033165 16777216 (0.30000001) 5033165 8388608 (0.60000002) 5033165 33554432 (0.15000001) 16106127 268435456 (0.059999999)
  ExtraSamples 338 (0x152) SHORT: 2 (UnassociatedAlpha 2 (0x2))

[zjniu]

Nope, I'm running the code exactly as is using tifffile 2023.8.12.

[zjniu]

Could you provide me an example TIFF from your end that is considered a "good file" and the code you used to generate it?

[manthey]

@zjniu Your code snippet worked for me directly.

[cgohlke]

Re 2023_05_23_pw020_ctrl_well1.tif: it appears the TIFF was originally created by tifffile with separate samples and then later rewritten by another software with interlaced samples, at which point the metadata in the ImageDescription tag got out of sync. The same could have happened with OME-TIFF or ImageJ format.

[zjniu]

@cgohlke Thanks for the insight. I'm not sure how that happened as that should have been a direct output by tifffile. Regardless, @manthey, I uploaded the file I created using the code snippet above and it now works.