I was recording dimension and resolution data for a set of microCT scans I’ve been working on and I noticed some issues between 16-bit and 8-bit nrrd volumes, resampled 8-bit (to larger slice thickness for modeling), and between the way Fiji and Slicer reads the volumes.
Rescaling to 8-bits: I have followed the protocol on the SlicerMorph site for rescaling my 16-bit nrrd to 8-bit (W_2020/Lab11_SlicerPlusPlus at master · SlicerMorph/W_2020 · GitHub). There seems to be a difference between 4.10.2 and 4.11. For a 4gb volume at 16bit, my 8bit volume (generated in 4.10.2) shows up as a 700mb file in my file explorer, but when I open it in Fiji, it shows it as 2.1gb. It also shows the dimensions in microns instead of mm, but the same volume shows the correct dimensions in Slicer.
When I re-import the DICOM slices into Slicer 4.11 and re-save the volume and rescale, I’m getting the 8bit to show in my file explorer as 2.1gb, but the mm/micron issue with Fiji is the same.
Resampling: Since I don’t need to generate a 3D model from an 82 micron scan, I resampled to 0.1637 mm using Resample Scalar Volume. The new volume shows the correct dimensions (still showing as microns though in Fiji), but shows the Scalar Range as 0 to 254 instead of 0 to 255. This happens in both Slicer 4.10.2 and 4.11.
Should I be doing something differently?
Any ideas why there’s a difference between Fiji and Slicer after rescaling to 8bit or why a grayscale value is lost when resampling?
Sorry if it’s confusing! FYI the DICOMs were exported from a NorthStar.
Terrie
In my experience FIJI doesn’t read the units correctly. So I am not surprised that you are seeing a mm to micron difference.
As for data size change, the default in Slicer is to compress the volumes. So 2.1GB stack may end up 700MB on disk (file explorer), because it is compressed. FIJI doesn’t compress the NRRD volumes, AFAIK. If you have installed SlicerMorph in 4.11, we disable compression for volume nodes to improve read/write times for large datasets. So that might explain while your datasets from 4.10.2 ended up being smaller on disk than what it needs to be. You can manually uncheck the compress option in v4.10.2 in the save as dialog box.
As for why you are not getting the max as 255 the highest intensity value, I am not sure…
File size may be smaller due to image compression, but since it is exactly 3x more, it is also possible that Fiji chooses to store the image in 3 channels (RGB). You can try to change color mode to grayscale.
Check Volume module / Volume information / Number of scalars. If you see 3 there then it confirms that Fiji converted the grayscale image to RGB, needlessly tripling the memory usage.
When you resample your image to lower resolution then small details in the image are lost. For example, if you only had a few, isolated voxels that had the intensity value of 255 then it is very likely that you will not have a value of 255 in the downsampled output. You can slightly increase the quality by applying antialiasing filter (low-pass filter, such as Gaussian smoothing should suffice), but it rarely makes a practical difference (see this discussion for details).
Thank you Andras! This all makes sense. I don’t think losing 255 would affect my 3D models since they’re mostly dry bone, but I might try the antialiasing filter on some volumes to see if I notice a difference.
Would it make a difference if I resample the resolution first then convert to 8-bit? I normally just convert to 8-bit first to reduce the file size and depending on the complexity of the specimen and sometimes reduce the resolution if the volume is still difficult to work with.
