"Image dimensions do not make sense"? about mricrogl10_old HOT 10 CLOSED

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.

from mricrogl10_old.

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.

from mricrogl10_old.

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.

from mricrogl10_old.

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).

from mricrogl10_old.

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?

from mricrogl10_old.

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?

from mricrogl10_old.

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).

from mricrogl10_old.

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.

from mricrogl10_old.

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

from mricrogl10_old.

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

from mricrogl10_old.