These look like valid DICOMs, but are unusual and Slicer might not be the ideal tool for these.
- Unusual transfer syntax 1.2.840.10008.1.2.4.91 JPEG 2000 (potentially lossy) Image Compression. This may confound some readers, I would suggest raw storage as DICOM does not require readers to support this format (gdcm and dcmtk can convert). These were created by Osirix, and it can be set to save data as raw.
- Unusual Instance Numbers (0020,0013): [ 27 32 33 147 153 184 190 218 219 224 225 230 231 345 351 379 386 392 423 437]. Again, this is legal, as DICOM does not require sequential or even unique values. However, this often suggests files are missing.
- Uneven spacing between slices. Distance from the first slice is [0 4.88281 5.85931 117.188 123.047 153.32 159.18 186.523 187.5 192.383 193.359 198.242 199.219 310.547 316.406 343.75 350.586 356.445 386.719 400.391]. Again, this is legal but might suggest some slices are lost, and frustrates tools that expect equal slice spacing.
- This fusion image uses RGB with 8-bits per channel. Again, this is legal, but does limit utility. 24-bit RGB allows just 256 unique gray levels, and therefore less dynamic range than 12-bit (4096 grays) or 16-bit (65536 grays) data. Further, since there are 3 channels, it is not scalar. Slicer is really optimized for scalar (single channel) data. Consider a CT image with a single channel reporting Hounsfield units in the range -1000…1000. The relative brightness between voxels is explicit. In contrast, consider two Red/Green/Blue voxels, one with values 255/0/0 (Red) and the other with 0/0/255 (Blue). The red voxel is brighter to the human eye (as it is more sensitive to red) while the blue voxel is hotter if the units is a Kelvin color scale. With an RGB image, the colors are “baked in”, which will limit the utility of Slicer.
The dcm2niix module for Slicer should convert these for you. It can interpolate from the 20 slices to create 40 evenly spaced slices, which might be useful.