"Image dimensions do not make sense"?

[TheChymera]

I have a few supersampled NIfTI's I would like to visualize with MRIcroGL, they seem to work down to a resoution of 0.018x0.018x0.018mm, they display as a homogenous bIue (?) volume at 0.017x0.017x0.017mm, and fail to open downwards from 0.016x0.016x0.016mm, giving the following error:

Image dimensions do not make sense (x*y*z*bpp = 840*1275*643*4)

Here are the images, the original image from which they were supersampled, and the code with which I did so. I am unsure whether this is an MRIcroGL issue, or whether the files is simply corrupted, but I don't see why the dimensionality should not make sense.

[neurolabusc]

I think you are exceeding the capabilities of your graphics card. For such data, you may want to rely on MRIcron's CPU based approach - it is much slower, but is much less limited for very large volumes. Since SNR is based on volume, I think that modern graphics cards should handle most real world MRI or CT datasets. I also expect graphics cards improvements to grow faster than scanner capabilities over the next few years.

If you do want to view your dataset with MRIcroGL, you may want to click on the 'Advanced' preferences button and try adjusting the MaxVox value. This will depend on your graphic card, but for me MaxVox=512 allowed me to visualize your volume, albeit down sampled. If this does not work for you, you may want to tell me the version you are using (I tried the master source code on MacOS).

If you only want to visualize the outside surface (without clip planes and cutouts), this would be a good application for using a surface renderer (e.g. Surfice) instead of a volume renderer. As a rule of thumb, the demands for a volume renderer go up with the cube of your resolution (^3), while with a surface renderer they scale with the square (^2). So doubling the resolution increases the surface area by a factor of 4, but the volume by a factor of 8.

[TheChymera]

turns out my .MRIcroGL/MRIcroGL.ini file contained MaxVox=2048. I tried changing that to both 512 and now 10000, but neither could change the visual output.

[neurolabusc]

You might want to try out the latest pre-release. Like MRIcron, I am waiting for the next stable dcm2niix (which will probably come in another week or so, when I can get my hands on a Philips DTI validation dataset) before generating a stable release. I assume you are running Linux - you may want to run glxinfo and make sure you are running the latest graphics drivers. Unfortunately, OpenGL support on Linux remains a bit spotty. Again, with my Mac using integrated graphics I can support a MaxVox of 512. In any case, since the software will downsample volumes greater than MaxVox to MaxVox, you would probably be better served by not supersampling your dataset to such an extreme resolution if you want to use MRIcroGL (or consider purchasing a different graphics card).

[TheChymera]

I'm not supersampling it to get any additional detail (because that is plainly impossible). I am looking to use a higher resolution template for plotting and 3D printing, but I want it transformed to the shape/space of my hitherto used template (the more highly resolved one is from a a histological preparation with corresponding artefacts). So in order to preserve the resolution in ANTs, I cannot simply transform the more highly resolved image to the old template (that would resize it), instead I need to first supersample the template, and then transform the more highly resolved image to that. I just want to inspect the process visually along the way.

I tried to use MRIcron, but it does not currently compile. As for 3D rendering, does MRIcropGL still do that internally even if I e.g. only select the multiplanar view?

[neurolabusc]

Does the pre-compiled pre-releases of MRIcron and MRIcroGL I linked work? (with the MRIcroGL MaxVox reduced)? If not, it is hard to provide troubleshooting without any other info. Perhaps you could share your glxinfo. Even for 2D slices the whole volume is loaded onto the GPU - it is a single Texture3D object, so the slices require just a single draw call. For your purposes, MRIcron should be fine for inspecting 2D images. Older versions of MRIcron should work fine, right?

[TheChymera]

As described here, MRIcron has also failed, though only at 0.016 isntead of at 0.017 as MRIcroGL did before. I tried reducing MayVox all the way to 32, and the most I could do is to get MRIcroGL to plot the 0.017 image (which starts working at 256).

[neurolabusc]

The software now generates a clearer error "Image exceeds 2gb" if any 3D volume is larger than 2gb. If you develop a patch for this, please submit a pull request. I took a quick look at this, and with my hardware I was able to support huge files on MacOS but not 64-bit Linux. In the short term, you can also use MRIcron using a Mac computer (I have not tried Windows). I am closing this issue as I now generate a meaningful warning and this seems like an edge case where MRIcroGL is not the appropriate tool.

[TheChymera]

@neurolabusc - the images I am having issues with do not exceed 2GB, though, they're 150 and 180MB, respectively.

[neurolabusc]

The files that fail require >2Gb when you extract the gz files (which you need to do to read the data). The GZ compression is very successful on your images because there is a lot of air (which is all set to zero). However, for speed of display we need to decompress your data when we load these files.

fslhd DSURQEc_s16micron_masked.nii.gz
data_type      INT32
dim1           787
dim2           1195
dim3           602

4 x 787 x 1195 x 602 = 2264639720 bytes = 2.26 Gb

If you only want to generate a surface for 3D printing, you could reduce the precision from INT32 to INT16 which would halve the uncompressed size of your data, e.g. fslmaths DSURQEc_s16micron_masked.nii.gz 16_16bit -odt short

[neurolabusc]

Updated code will load very large images. For most modern video cards these will have to be down sampled by your MaxVox. On my GTX 1080 Ti, I am able to view your 741 x 1125 x 567 at full resolution, but need to apply a MaxVox for your 787 x 1195 x 602 image. I am not sure if this is a limit of my hardware or code, but at the moment the software exceeds the capabilities of virtually all hardware.