Actually there are no restrictions in the code, at least none that I explicitly put there. I checked, and really, no data can be entered that is beyond 2500 header and 5000x2500 (X x Y dimensions) - even worse, if I move the slider for Z up to 1567, then Slicer catches an exception, saying Bad Allocation.
Generic Warning: In D:\D\S\Slicer-4101-build\VTK\IO\Image\vtkImageReader2.cxx, line 757
File operation failed. row = 0, Read = 5000, FilePos = -1
Unable to allocate 19550000000 elements of size 1 bytes.
“Slicer has caught an internal error.\n\nYou may be able to continue from this point, but results are undefined.\n\nSuggested action is to save your work and restart.\n\nIf you have a repeatable sequence of steps that causes this message, please report the issue following instructions available at http://slicer.org\n\n\nThe message detail is:\n\nException thrown in event: bad allocation”
19550000000 indeed equals 5000 x 2500 x 1564.
This equals around 18GB of data if we take an 8bit pixel color depth, if I calculated correctly.
This part is beyond me, so we still might need someone else to chime in!
As for the header, I will look into this. Also downloading your data right now.
Okay, too long time passed to edit my previous post
So there were restrictions and they were arbitrary. But not in the code but in the UI file…
I edited it and checked in the changes into master.
Also checked in a slightly newer version of the python file.
Thanks @nagy.attila. I will give a try.
As for the limits, I think it might be useful to precalculate the datasize as you did above, and give a warning about its consequences.
I think in general, we need a consistent way of resampling the stack without needing to load the entire stack into the Slicer. This will come in handy for datasets from high-resolution mCT as well as microscopy to load into computer with limited resources. @smrolfe started one sometime ago, so there might be some synergy there…