# Ultrasound in YBR\_Full\_422 not displayed correctly?

**URL:** <https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552>\
**Category:** Support\
**Created:** [September 24, 2019, 7:40pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552 "2019-09-24T19:40:56Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![hina-shah](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/hina-shah/32/695_2.png) [@hina-shah](https://discourse.slicer.org/u/hina-shah)\
**Post date:** [September 24, 2019, 7:40pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/1 "2019-09-24T19:40:56Z")

</div>

Hello,

I have an ultrasound image dicom that has a PhotometricInterpretation as YBR\_FULL\_422. Hence loading it results in a display like this:  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/a/2/a2a33140100f3a436e6613ec6a688d767887272e.png)

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

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 24, 2019, 7:53pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/2 "2019-09-24T19:53:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [September 24, 2019, 8:01pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/3 "2019-09-24T20:01:27Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![Chris\_Rorden](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chris_rorden/32/4073_2.png) [@Chris\_Rorden](https://discourse.slicer.org/u/Chris_Rorden)\
**Post date:** [September 24, 2019, 9:25pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/4 "2019-09-24T21:25:49Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![hina-shah](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/hina-shah/32/695_2.png) [@hina-shah](https://discourse.slicer.org/u/hina-shah)\
**Post date:** [September 25, 2019, 2:56am UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/5 "2019-09-25T02:56:58Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [September 25, 2019, 7:45am UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/6 "2019-09-25T07:45:18Z")

</div>

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](https://github.com/InsightSoftwareConsortium/ITK/pull/822) (sorry i gave up) and it is currently [re-opened](https://github.com/InsightSoftwareConsortium/ITK/pull/1240) 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)](https://github.com/InsightSoftwareConsortium/ITK/blob/75615f60381ef74bf8d22d39c982380fbdc65fa9/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx#L347) and it is overriden with [another hack in GDCMIO](https://github.com/InsightSoftwareConsortium/ITK/blob/75615f60381ef74bf8d22d39c982380fbdc65fa9/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L500).

**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](https://github.com/InsightSoftwareConsortium/ITK/pull/1240#issuecomment-529763848)

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 25, 2019, 11:37am UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/7 "2019-09-25T11:37:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [September 25, 2019, 6:53pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/8 "2019-09-25T18:53:52Z")

</div>

> [@hina-shah](#):
>
> 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?

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).

---

<div class="post-metadata">

**Author:** ![hina-shah](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/hina-shah/32/695_2.png) [@hina-shah](https://discourse.slicer.org/u/hina-shah)\
**Post date:** [September 25, 2019, 8:12pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/9 "2019-09-25T20:12:47Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [September 26, 2019, 12:18am UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/10 "2019-09-26T00:18:27Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [September 26, 2019, 10:26am UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/11 "2019-09-26T10:26:45Z")

</div>

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

 ![20190926-115629](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/6/1/61a7c7b4fa2d772149e5213f1621a71f43dcbec9.png)

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [September 26, 2019, 12:09pm UTC](https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/12 "2019-09-26T12:09:44Z")

</div>

In GDCM [these 2 lines: 861, 862](https://github.com/InsightSoftwareConsortium/ITK/blob/2b82a99b888657fb5edcc7f02ae576860ac33b10/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmJPEGBITSCodec.hxx#L861) make a difference. If commented out - image colors for lossy Jpeg are correct. It not a request to change it now, just FYI.