MMelQin
commented
2 years ago @jlvahldiek Thanks for filing this bug.
Yes, the DICOMSeriesToVolumeOperator is where the DICOM pixel data is converted into internal image representation, and as you rightly pointed out, the conversion, as of now, assumes the Photometric Interpretation of MONOCHROME2, and the VOI LUT is not used either. It is a known limitation which could have been documented better.
Similar limitation also exists in Simple ITK, with its GDCMImageIO, per this discussion , and this example.
I think it is right to change MONOCHROME1 to MONOCHROME2 on converting series to volume, so this way, the downstream operator, e.g. inference, would have consistency.
What the thing that came to mind is, the segmentation images will typically have 0 as background, and non zero unsigned INT as organ or lesion mask. On wrapping the seg image as DICOM Secondary Capture or Segmentation OID, the Photometric Interpretation is set to MONOCHROME2. When overlaid with the original series of MONOCHROME1, then it will required the viewer to display the images with a consistent Photometric Interpretation.
@rahul-imaging comments?
DICOM images having Photometric Interpretation of MONOCHROME1 are not inverted by monai-deploy-app-sdk.
The class DICOMSOPInstance reads in pixel_array via pydicom.dcmread(). Pydicom itself does not care about Photometric Interpretation and just delivers the stored pixel array (https://github.com/pydicom/pydicom/issues/783).
When using DICOMDataloaderOperator and DICOMSeriesToVolumeOperator images having Photometric Interpretation of MONOCHROME1 need to be inverted before they are passed to any inference operator.
I consider the actual behavior to be a bug (errorneous inverted images probably will have a huge impact on model's inference performance). I would like to contribute a fix. Where should the needed pixel array inversion of MONOCHROME1 DICOMs take place? Probably it best fits anywhere into DICOMSeriesToVolumeOperator...
Thank you.