what I expect is that the input and exported DICOM should be the same in image voxel data at least (DICOM tags can differ, that’s fine).
BUT, it’s not the case! here, some statistics of the two DICOMs:
Can you get a screenshot of what shows in the Slicer “Volume Information” section in the Volumes module? Which does it agree with, the pre-import or post-export data?
The “Volume Information” section in Volume Module is shown in screenshot below:
I’m not sure which info I should look for, but from the information I can see in common between the statistics I shared before and the Volume Information is “Scalar Range” which seems to agree with Post-Export data (left side statistics window below:
Thanks. One other place to look would be to see if you got any errors or warnings when importing from DICOM. You can see an error log by clicking on the “X” in the lower right of the Slicer window (which is red if there are any new messages there since the last time you opened it).
I agree this shouldn’t be happening. My guess is that there is something which is either incorrect, inconsistent, or incorrectly interpreted by Slicer in the DICOM headers for this image volume.
In Slicer, is the scalar range the same is the same in the original image and in the image that has gone through DICOM export and import? If yes, then probably the difference is just in raw (manufacturer dependent) pixel values, which DICOM exporters are free to choose, along with the corresponding modality LUT (Rescale Slope (0028, 1053) and Rescale Intercept (0028, 1052)).
Maybe modality LUT was not applied when you loaded the data into Mevislab and you are comparing raw voxel values. It is normal to have difference in range of raw voxel values when you import and re-export DICOM.
@mikebind interesting discussion in the link you shared.
When I open my original dicom file in Mevislab, it’s type is unsigned int16 (right info box), while exported dicom is int16:
If your original data is 12-bit, then the maximum (raw) value possible should be 4096, and the imported version exceeds this. This could be altered by the RescaleSlope and RescaleIntercept tags, so check those, but this suggests that perhaps one or more of the non-data bit values is being treated as if it were part of the data.
This looks all good. Bits allocated, bits stored, high bit fields should be fine, as we don’t see any sign of overflow or saturation in the images. These bit fields were introduced when sometimes additional image masks were stored in unused bits of the pixel data, but these are very rarely used nowadays, and not used by Slicer’s DICOM exporter either, so it is OK to use up all the available 16 bits in the pixel data to store the raw voxel values.
It seems that the problem is that mevislab does not apply modality LUT on DICOM import. I’m very surprised that this is not already part of the DICOM importer, because without modality LUT you get raw pixels that are not usable for much. It seems that in mevislab you need to add a DicomLUT box or ApplyDicomPixelModifier box (or some other filters) for every DICOM importer box to get usable image voxel values.