Page MenuHomePhabricator

US DICOM images are displayed turquoise and LUT cannot be changed
Open, NormalPublic

Description

The data provided by T27554 is shown with a turquoise LUT. This LUT cannot be changed, even if we select a new colormap in the datamanager for the node.

Event Timeline

floca triaged this task as Normal priority.Jul 19 2020, 3:08 PM
floca created this task.

@floca: This would be the most urgent from the tasks, as I did't find a work around so far.

Any update on this issue?

The Photometric Interpretation tag (0028,0004) of the Philips US image is set to YBR_FULL_422 and my first guess is that we do not take this tag fully into account, leading to a misinterpetation as RGB values while reading the data.

@kleesiek thanks for the reminder after summer break.

I digged a bit deeper. Wrong photometric interpretation is a known error in GDCM (which is used as a reader internaly). See i.a.:
https://discourse.slicer.org/t/ultrasound-in-ybr-full-422-not-displayed-correctly/8552/10

Basically I see 3 solutions (none of it is a fast track 😒 )

  1. We try to fix GDCM
  2. We check if DCMTK does better and use it
  3. We fix it after loading (simelar to CEST where the data is normalized after it was first time loaded)

I have dislike #1 most, as it is unclear who much work it will be and if we succeed in the end, additionally seeing the development of GDCM it is unclear if it is a longterm good investment.
#2 and #3 would in one or the other way mean a bigger refactoring of the current reader classes (#2 more then #3).
In case of #2 and #3 i think it would also be good to introduce a dedicated reader service for US images and an associated mime type, both with high priority so that it overrules normal DICOM readers in case of ultra sound (especialy #3 would kept cleaner). Further own reader and mime type would help us to also adress the other issues raised under T27554.
Want to discuss it.

Just checked GDCM 3.0.7 if by chance the issue was fixed there, unfortunately not.

floca added a comment.Sep 11 2020, 3:15 PM

Just checked GDCM 3.0.7 if by chance the issue was fixed there, unfortunately not.

Damn. Thanks for the effort!

Discussion result: if GDCM does not fix it fast enough, we should take option 3 (as we very likely need a dedicated DICOM US mime type anyways).