Weasis shows green hues instead of black in JPEG-compressed Ultrasound images

[crispinus2]

Hallo,
we have a problem with the current stable release of Weasis (v3.6.1) on Windows. The DICOM files generated by our SonoScape P40 ultrasound device are rendered with a green background instead of the black color which is expected. The error occurs as soon as compression for JPEG images is switched on in the ultrasound device, no matter whether it's lossless or lossy compression.
Attached is an example DICOM-file with a lossy compression on quality setting "high". This file can be previewed in the Orthanc Web preview without issues, the contained JPEG is displayed correctly by GIMP after extracting it with dcmdump from the DICOM file.
PhotometricInterpretation tag is set to "RGB", which seems correct as GIMP shows the same color model when opening the extracted raw data.
Help is appreciated.

Screenshot of Weasis misbehaviour:

Sample file used for the screenshot:

c63d93be-53d2-4892-8e51-20ea37c20e32.zip

[nroduit]

The DICOM standard does not exclude having a 1.2.840.10008.1.2.4.50 syntax with an RGB color model but in practice using RGB for jpeg lossy does not make sense. If there really is a manufacturer who configures his equipment to produce jpeg lossy with an RGB model, you should ask him why he does this.

On the other hand in Weasis and dcm4che, the RGB model is forced to become YBR_FULL_422 for the syntax 1.2.840.10008.1.2.4.50 because it is an error that is made by some manufacturers who define an RGB model when the data is actually in YBR.

In summary Weasis could display this image correctly but in practice this type of image should not exist, however there are many images with a fake RGB models instead of YBR.

[crispinus2]

Hallo,
thanks for your feedback on this issue. I think the chances are quite low to get the device's manufacturer (SonoScape) to change its behaviour, as all other DICOM viewers I tested so far don't have a problem with the supplied file.
I conclude that the image is correctly specified as RGB, because it internally uses a RGB color model (that is confirmed by the image details when opening the extracted image data from the DICOM file in GIMP). And this image indeed exists, as I got it from my device. SonoScape is quite a big (chinese) vendor here in Germany, so there are many users here which could suffer from this problem. As the cine captures from this device are affected by this issue (because they are sent as compressed JPEG frames), too, I see no other way but using another viewer than Weasis for displaying this data at the moment, which is a sad fact as I DO like Weasis very much in fact.
So I hope for suggestions how to fix this, as in fact the devices's vendor won't "fix" it, I think (as he hasn't made any error - he specifies that RGB data is send, and RGB data is sent). In fact, stating to send RGB data but sending other data types instead is an error and those manufacturers should correct their devices' behaviour.
As we are using Orthanc for PACS storage, I could have a DICOM tag added to incoming instances, if that would Weasis help to display the file correctly.
I'm also prepared to supply a pull request, if you'd direct me which kind of solution you could imagine/would accept for this problem besides removing the forced model change inside of Weasis, which you apparently don't want to. Perhaps, adding a kind of configuration option for the color model force behaviour would be a viable solution?

[nroduit]

This image displays correctly in older versions of Weasis (try 2.6.1).

The question is not how to fix this problem, but rather how to deal with images that have an RGB model but actually have YBR data.

In the development of Weasis we have always tried to be as close as possible to the DICOM standard.This forced color model conversion is one of the rare adaptations made to the standard because these images exist while those in lossy jpeg with an RGB model, this is the first time I've seen them.

The only solution to handle both situations would be to add an option to display one or the other mode.

However from a data compression point of view, producing lossy jpeg images with an RGB model remains an absurdity even if it is not forbidden in DICOM.

[crispinus2]

Besides the fact that I now consider to let Orthanc transcode all incoming compressed RGB data from this ultrasound device to YBR to save space, wouldn't it be possible to restrict the application of this forced YUV interpretation to the manufacturers / devices where the misbehaviour of sending YBR but specifying RGB as PhotometricInterpretation is known? This information could be gained from Manufacturer or ManufacturerModelName tags.

[nroduit]

I publish a fix ea29756

Let me know if you see other manufacturers with these kind of images

[crispinus2]

Thanks for the quick fix. Works for me, the files are displayed in correct colors now.