I have a series of multi-page tiffs. That is, I have several files of the form <file_name>_T.tif and each file contains multiple pages representing a stack. If I read this series in Paraview using the default properties, I’m getting a crash. If instead of the default properties, I uncheck “Read As Image Stack” then I seem to get the behavior that I was expecting. In hindsight, this somewhat makes sense, but it took me some time to figure out. “Read As Image Stack” seems ambiguous in this particular use case, and the code appears to be confused about which grouping represents the stack.
At this point, I don’t really have a specific question, but if anyone has thoughts related to whether this was only user-error or whether this is something that needs to be changed in code, to prevent the crash, I’d be interested. Thanks.
This python script will create some sample data. (The crash produced by this data is slightly different than what I was seeing on my actual data, but I suspect it is the same root issue).
from tifffile import imsave
import numpy as np
num_pages=10
for i in range(3):
di = np.ndarray(shape=(num_pages, 10,20), dtype=np.int16)
di[()] = np.arange(i*50, i*50+(200*num_pages)).reshape(num_pages,10,20)
imsave('testMultiPage_T'+str(i)+'.tif', di)
The assumption with Read As Image Stack is that the series of image files contain individual 2D images, not stacks in each file. Are your stacks in each file the same dimension? I could imagine a crash happening if the dimensions of the stacks differ.
Since you figured out how to read your data in ParaView, perhaps this is a case where a better option name or better documentation would have saved you some time?
Thanks, Corey. Yes, my scenario violated that assumption. Each file contained multiple 2D images. So, each file was a “stack” and the group of files formed the “time series”. As you say, once I figured out to turn off that switch, everything worked. My preference would be we find a way to catch the scenario in code and report an informative user message, avoiding the actual crash.
I don’t remember all of the details to the crash. In vtkImageReader2’s RequestInformation, there is a snippet that does: “// if a list of file names is supplied, set slice extent”. The 3rd dimension’s extents were already something meaningful in this case. Thereafter, the code is confused about the dimensions. It sizes an array based on the “number of files” but then uses that array based on the (larger) data in a file. All that said, I don’t personally know the right place to catch the problem.