Hello, everyone, I’m trying to load a tiff data of 4,6 GB size and this message appears:
Any advices?
hit Ctrl+0 and look at the full log and see if there are any more information about this error? Are you certain file is not corrupt? Can you open with some other software e.g., FiJi
Yes!! It’s not corrupt, I was able to open with Fiji.
The full error is this:
Problem reading the row: 648
Algorithm vtkITKArchetypeImageSeriesScalarReader (0000010D2CA011E0) returned failure for request: vtkInformation (0000010D842E6960)
Debug: Off
Modified Time: 6736291
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FORWARD_DIRECTION: 0
ALGORITHM_AFTER_FORWARD: 1
FROM_OUTPUT_PORT: 0
vtkMRMLStorageNode::ReadData: Failed to read node raw-hd_1 (vtkMRMLMultiVolumeNode1) from filename=‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’
ReadData: This is not a nrrd file
vtkMRMLStorageNode::ReadData: Failed to read node raw-hd_1 (vtkMRMLDiffusionWeightedVolumeNode1) from filename=‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Reading of file ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ failed: FileFormatError Number of files listed in the node is 0. File reader says it was able to read 1 files. File reader used the archetype file name of ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ (first filename: ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’)
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Reading of file ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ failed: FileFormatError Number of files listed in the node is 0. File reader says it was able to read 1 files. File reader used the archetype file name of ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ (first filename: ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’)
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Cannot read ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ file as a volume of type ‘DiffusionTensorVolume’. Details: FileFormatError.
vtkMRMLStorageNode::ReadData: Failed to read node raw-hd_1 (vtkMRMLDiffusionTensorVolumeNode1) from filename=‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’
ReadData: This is not a nrrd file
vtkMRMLStorageNode::ReadData: Failed to read node raw-hd_1 (vtkMRMLVectorVolumeNode1) from filename=‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Failed to instantiate a file reader
vtkMRMLStorageNode::ReadData: Failed to read node raw-hd_1 (vtkMRMLVectorVolumeNode2) from filename=‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Reading of file ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ failed: FileFormatError Number of files listed in the node is 0. File reader says it was able to read 1 files. File reader used the archetype file name of ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ (first filename: ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’)
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Reading of file ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ failed: FileFormatError Number of files listed in the node is 0. File reader says it was able to read 1 files. File reader used the archetype file name of ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ (first filename: ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’)
vtkMRMLVolumeArchetypeStorageNode::ReadDataInternal: Cannot read ‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’ file as a volume of type ‘Volume’. Details: FileFormatError.
vtkMRMLStorageNode::ReadData: Failed to read node raw-hd_1 (vtkMRMLScalarVolumeNode1) from filename=‘C:/Users/Rafaela/Desktop/Fabricio/Scapteromys_tumidus_NHMUK_671657/Scapteromys_tumidus_NHMUK_671657/raw-hd.tif’
This is with regular add data, right? Did you try with the ImageStacks from the SlicerMorph extension?
Yes, it’s with the regular add data! I can’t use ImageStacks because the file I’m trying to open is just one large file; I don’t have the individual micro-CT scans needed to use ImageStacks.
Doesn’t matter, imagestacks support the multi-frame tiffs like yours, and it will display the ordering of the dimensions, which I suspect the issue with this specific file.
If you can share the file, I can take a look. Meanwhile, if you can try exporting as NRRD from Fiji and try loading that way.
Can I send you an email with the files?
you can upload here: https://faculty.washington.edu/maga/data_dropbox
I am trying to diagnose why fiji opens the file, but slicer doesn;t. Stll your file contents are indeed corrupted. The first 197 slices are variations of this, even if you were to load this into Slicer, you won’t be able to properly use them (these screenshots are from Fiji)
This is the diagnosis from claude, and I agree you should go back to the source and ask an uncorrupt version of the file, possibly as a proper image sequence as opposed to multiframe tiff.
There are two separate defects, not one
I walked the file’s directory structure directly (no libtiff) and then decoded strips with my own LZW decoder to see where each one breaks.
The file: /tmp/raw-hd.tif, 4,756,310,985 bytes (4.43 GiB). Header is II*\0 — magic 42, classic TIFF, not BigTIFF. 1999 pages, 1124 × 978, 16-bit, LZW, one strip per page, no predictor. Page 0 carries ImageDescription = "BoundingBox 0 26.267 0 22.852 0 46.7332", which against 1124 × 978 × 1999 gives 23.37 µm isotropic voxels — worth keeping, he’ll need it.
Defect A — the compressed data in the first 197 slices is corrupt
188 of the first 197 slices (Fiji slices 1–197) fail to LZW-decode. Each one decodes correctly for a while and then the code stream desyncs into noise — which is precisely what your screenshots show: clean anatomy on top, static below. Slice 161 is the variant where the stream hits an end-of-information code instead, so the remainder fills with black.
The smoking gun: slice 1 decodes 1,458,895 bytes before desyncing. At 2248 bytes per row, that is row 648.97. That is his Problem reading the row: 648. The error he reported is thrown on the very first slice.
This is real byte-level damage to the compressed streams. It is not recoverable — the information is gone. Nine of those 197 slices happen to be intact (7, 8, 178 among them), which is just luck about where the damage fell.
Defect B — the file blows past the 4 GiB ceiling of classic TIFF
Classic TIFF stores every internal offset in 32 bits, so it can only address 4 GiB. This file is 440 MiB beyond that. From slice 1797 on, the stored StripOffsets have wrapped around and point back into the first few MB of the file — slice 1797’s offset is 1,443,814, which lands in the middle of slice 1’s pixel data. libtiff dutifully seeks there and decodes garbage.
This half is repairable. The data is all physically present and laid out sequentially — I verified the true extent runs 8 .. 4,756,310,985, exactly the file size, so nothing is missing. Adding 2³² to the wrapped offsets recovers those slices cleanly; I decoded 1797, 1798, 1901 and 1999 that way and they come back as sane CT data with statistics continuous with their neighbours.
Your “data ends at 1801” reading is this defect — structurally the last slice with a valid offset is 1796, and the few after it decode into recognizable-looking wreckage before it becomes obviously noise.
What this means
| Fiji slices | Count | State |
|---|---|---|
| 1–197 | 197 | Corrupt, unrecoverable (9 intact by chance) |
| 198–1796 | 1599 | Fine as-is |
| 1797–1999 | 203 | Recoverable by unwrapping the offsets |
So 1,802 of 1,999 slices are salvageable, contiguous, and the loss is at the leading end of the specimen — from your screenshots, mostly air plus the first appearance of that small bone ring around 161–183.
The file is damaged and he should get a fresh copy from whoever produced the scan. Whoever exports it must not write a >4 GiB classic TIFF — the options are BigTIFF, an image sequence of single-page TIFFs, or best, NRRD directly, which also carries the voxel size.
ImageJ’s LZW decoder has no error branch
Because Fiji isn’t reading it correctly either. It’s showing him fabricated pixels, not recovering anything — those noise and black bands in your screenshots are the failure. The difference is entirely in what each reader does when a decode goes wrong.