Hello,
I have an ultrasound image dicom that has a PhotometricInterpretation as YBR_FULL_422. Hence loading it results in a display like this:
Is there anything that I can do to display it correctly? I’m trying to get to the actual RGB data in python to process the image, and this is a multi-frame ultrasound dicom.
Thanks!
Hina
Hi @hina-shah - you can probably read it directly with pydicom (import dicom in slicer). We don’t have a direct importer for this, but a dicom plugin that detects and loads as vector volume would be feasible.
As far as I remember, this is a bug in ITK’s color image reader (color components are mixed up). It seems that you have a B-mode image, which is a single scalar, so you can ignore this appearance and use “Vector to scalar volume” module to create a scalar image.
I agree with @pieper that it would be nice to address this automatically in a custom DICOM plugin (but even better, in ITK).
@hina-shah is this an image you can share? It would be nice to test, but I am pretty sure dcm2niix can convert this.Slicer supports RGB NIfTI images. With this route, you install the “SlicerDcm2nii” extension into slicer. After that, you would have the Dcm2niixGUI module installed and you could import images. I agree with @lassoan and @pieper that it would be more elegant to integrate this directly into slicer.
Thank you everyone for your suggestions!
@pieper: reading with pydicom, uncompresses, but does not convert to rgb - unless I’m doing something wrong. I tried normal YCbCr->rgb conversion, but am getting some sort of noise.
@lassoan: the ultrasound actually loads fine with ITK-snap. Might have to see how the image is loaded there. Also, my aim is to read the tags embedded in the cine (which is yellow in color) - so I think I’d like to keep the rgb?
@Chris_Rorden: I’ll have to double check if I can share the image. But thanks for the tip!
It is known problem with GDCMIO, ITK-snap opens image as gray by default, if you’ll try set RGB it will be greenish blue too (Tools->Image Information->General->Display Mode).
There is one closed PR (sorry i gave up) and it is currently re-opened again, but seems to be frozen.
Generally, Ultrasound support in GDCM is very minimal, it doesn’t distinguish 2D+t and 3D, opens it as volume with fake geometry, cine frame time is not read, calibrated regions are not supported, spacing in GDCM is a kind of hack (reading 1st calibrated reagion) and it is overriden with another hack in GDCMIO.
Edit: BTW, currently that actual PR will not work, there was an attempt to use GDCM’s change photometric interpretation, but it crashes. If someone wants to try the working one i could re-created branch or just take from that post
Thanks for digging into this @issakomi 
Yes, it would be great if you can sort this out with the ITK team, as that would help Slicer and others.
Also, @hina-shah if you can share an example I’m sure the pydicom devs would also be interested.
ITK-snap just shows the first component by default. As I wrote above, you can use “Vector to scalar volume” module in Slicer to extract the first component, which contains the image intensity (and safely ignore the two chroma channels).
Thank you for pointing at the PR’s in ITK @issakomi. I didn’t notice that ITK-snap is a grayscale image but thanks for pointing to it! It looks like these changes will make their way into ITK in future if not immediately. I guess I’ll try to either work with the luminance channel as @lassoan suggested , or see if your conversions would give me non-noisy images.
@pieper: will share an anonymized data here.
Thank you all!
If you don’t need color information then you should use the luminance channel, because in case of ybr_full_422 encoding, color channels have half the spatial resolution of the luminance channel so you would potentially introduce artifacts by creating RGB image and converting that back to luminance (and also small potential errors due to floating point to integer conversion).
I totally agree. But i still think it is a problem with GDCMIO, because the information in those Ultrasound images is saved in colors, many Ultrasound images have a kind of color bar for easier interpretation, specially lossy Jpeg (YBR_FULL_422) is not very good to save shades of gray, IMHO
In GDCM these 2 lines: 861, 862 make a difference. If commented out - image colors for lossy Jpeg are correct. It not a request to change it now, just FYI.