I used https://www.microdicom.com/ as the outside DICOM viewer, where your uploaded anonymized image looked like this:
However, I just tried the same image using MATLAB’s dicomread(), and it shows in MATLAB like this:
Slicer’s “Volumes” module shows the “Scalar Type” of this image as “unsigned short”, which is the same as 16 bit unsigned integer. MATLAB shows the loaded image data type as “uint16”, which is also 16 bit unsigned integer. However, comparing the exact same voxel (755, 414) in each gives, 11919 in Slicer and 43995 in MATLAB. I’m a bit baffled by this.
OK, here’s a theory: The DICOM header says that 16 bits are allocated per pixel, but that only 15 bits actually store image information (and that the high bit is bit 14, which I think means that the 15th bit is related to the sign). However, I think MATLAB is ignoring this, and reading each pixel as a 16bit number. It must be, because the largest 15 bit number is 32767 (2^15-1), and 43995 is larger than this. Slicer, on the other hand, is ignoring the value in the 16th bit (which is what the DICOM standard says should be done) and only reading the remaining 15 (or 14, I’m not sure which because the 15th bit for 43995 would be 0). If I try dropping the 16th bit from the binary representation for 43995, I get 11227, which is pretty close to the values in Slicer, but not an exact match. Wait, just remembered that MATLAB indexing is 1-based, and Slicer indexing is 0-based, so the matching voxel index for (755, 414) in MATLAB would be (754, 413) in Slicer! And there, the voxel value is 11227, exactly 2^16 less than 43995! So, I think this must be what’s going on.
To summarize:
- The DICOM header is incorrect
- While it says that there are only 15 bits of image data in each pixel, there are in fact 16 bits of image data
- MATLAB very likely ignores this in the DICOM header, just reading that 16 bits are allocated to each pixel value, and then loading the pixel data as 16 bit unsigned integers
- Slicer, following the DICOM standard, ignores the 16th bit as the header indicates it should
I think the correct fix for you is to fix the DICOM headers of your images so that BitsStored is 16 and the HighBit is 15 (it looks to me in DICOM reference info that the HighBit is now always supposed to be one less than BitsStored). I think then they will load correctly in both Slicer and MATLAB.