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.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T27554 Handling of 2D and 2D+t sonographic (US) images | ||
| Resolved | floca | T27569 US DICOM images are displayed turquoise and LUT cannot be changed |
Event Timeline
Comment Actions
@floca: This would be the most urgent from the tasks, as I did't find a work around so far.
Comment Actions
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.
Comment Actions
@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 😒 )
- We try to fix GDCM
- We check if DCMTK does better and use it
- 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.
Comment Actions
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).
Comment Actions
GDCM 3.0.11 introduced a quickfic/hack to handle that correctly. (At least for the test data it works now.)