# Adding data failed

**URL:** <https://discourse.slicer.org/t/adding-data-failed/48182>\
**Category:** Support\
**Created:** [September 16, 2026, 4:34pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182 "2026-09-16T16:34:10Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![FabricioFO](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fabriciofo/32/82005_2.png) [@FabricioFO](https://discourse.slicer.org/u/FabricioFO)\
**Post date:** [September 16, 2026, 4:34pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/1 "2026-09-16T16:34:10Z")

</div>

Hello, everyone, I’m trying to load a tiff data of 4,6 GB size and this message appears:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/3/1/31f45a2683f2012c66b830cb5acc0df22cbd97ae.png)

Any advices?

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [September 16, 2026, 4:42pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/2 "2026-09-16T16:42:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![FabricioFO](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fabriciofo/32/82005_2.png) [@FabricioFO](https://discourse.slicer.org/u/FabricioFO)\
**Post date:** [September 16, 2026, 4:52pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/3 "2026-09-16T16:52:11Z")

</div>

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’

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [September 16, 2026, 5:01pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/4 "2026-09-16T17:01:33Z")

</div>

> [@FabricioFO](#):
>
> 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?

---

<div class="post-metadata">

**Author:** ![FabricioFO](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fabriciofo/32/82005_2.png) [@FabricioFO](https://discourse.slicer.org/u/FabricioFO)\
**Post date:** [September 16, 2026, 5:08pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/5 "2026-09-16T17:08:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [September 16, 2026, 5:22pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/6 "2026-09-16T17:22:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![FabricioFO](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fabriciofo/32/82005_2.png) [@FabricioFO](https://discourse.slicer.org/u/FabricioFO)\
**Post date:** [September 16, 2026, 5:26pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/7 "2026-09-16T17:26:01Z")

</div>

![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/1/8/18178e68a9e5c4bb50410a29a2aa69c86de43826.png)

But the button is grey. For this file specifically the image stacks is not working

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [September 16, 2026, 5:29pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/8 "2026-09-16T17:29:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![FabricioFO](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fabriciofo/32/82005_2.png) [@FabricioFO](https://discourse.slicer.org/u/FabricioFO)\
**Post date:** [September 16, 2026, 5:52pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/9 "2026-09-16T17:52:03Z")

</div>

Can I send you an email with the files?

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [September 16, 2026, 6:24pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/10 "2026-09-16T18:24:12Z")

</div>

you can upload here: [https://faculty.washington.edu/maga/data\_dropbox](https://faculty.washington.edu/maga/data_dropbox)

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [September 16, 2026, 8:05pm UTC](https://discourse.slicer.org/t/adding-data-failed/48182/11 "2026-09-16T20:05:28Z")

</div>

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)

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/6/e/6e5040ef6fcd32ad8e74e61bd95e4a41696ebe80.jpeg)

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/6/e/6e5040ef6fcd32ad8e74e61bd95e4a41696ebe80.jpeg)

 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/6/e/6e5040ef6fcd32ad8e74e61bd95e4a41696ebe80.jpeg)

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.