Rendered image showing wrong colors

Hello Everyone.

We are evaluating the ORTHANC server in combination with microscopy whole slide images and encountered two issues:

  1. Rendered frames show a red overlay:
    Request:*studies/*series/*instances/*frames/53/rendered
    Response Header: Content-Type: image/jpeg
    image

The OsmisViewer show the frames with the red colour overlay.
The Orthanc for Whole Slide Image Viewer does not use a frame-based system but shows the tiles in the correct colour.

How is it possible to render frames with Orthanc without the red overlay/stain?

  1. Microscopy Bulk Simple Annotations
    Is it possible to configure the Orthanc server to return microscopy bulk annotations? For the same DICOM image sequence, DCM4CHEE returns a link to download all annotations as binary, while Orthanc only returns a single value (-2.7911406768953069) for the tag: 00660022.

Server: Orthanc
Request: /studies//series/*/metadata
Result:
“006A0002”: {
“Value”: [
{
“0040A180”: {
“Value”: [
1
],
“vr”: “US”
},
00660022”: {
“Value”: [
-2.7911406768953069
],
“vr”: “OD”
},

Server: DCM4CHEE
Request: /studies//series//metadata
Result:
“006A0002”: {
“vr”: “SQ”,
“Value”: [
{
“0040A180”: {
“vr”: “US”,
“Value”: [
1
]
},
00660022”: {
“vr”: “OD”,
“BulkDataURI”: "
/DCM4CHEE/rs/studies//series//instances/*/bulkdata/006A0002/0/00660022"
},

With kind regards,
Christian

Hi Christian,

I guess that you are aware that we can not investigate anything without a sample file.

https://orthanc.uclouvain.be/book/users/support.html#discussing-a-minimal-working-example

Best regards,

Alain.

Dear Alain,

Of course. Thank you for your quick response. I found out the Orthanc TRANSCODING config causes the behaviour.

Please find a DICOM Whole Slide Image example stored at gdrive (230MB):

A request for rendering tiles:
*dicom-web/studies/2.25.317753984268209060558780446660059290395/series/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.2.0/instances/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.22.0/frames/1024/rendered

Logs when it is working:

I1117 13:36:46.307153 HttpServer.cpp:1262] (http) GET /dicom-web/studies/2.25.317753984268209060558780446660059290395/series/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.2.0/instances/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.22.0/frames/1024/rendered
I1117 13:36:46.307259 OrthancPlugins.cpp:2447] (plugins) Delegating HTTP request to plugin for URI: /dicom-web/studies/2.25.317753984268209060558780446660059290395/series/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.2.0/instances/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.22.0/frames/1024/rendered
I1117 13:36:46.307330 OrthancPlugins.cpp:4009] (plugins) Plugin making REST POST call to URI /tools/find (after plugins)
I1117 13:36:46.315801 ServerContext.cpp:1487] Number of candidate resources after fast DB filtering on main DICOM tags: 1
I1117 13:36:46.318686 ServerContext.cpp:1635] Number of matching resources: 1
I1117 13:36:46.320240 FilesystemStorage.cpp:161] Reading attachment "4538d1da-6de7-4f61-bc1f-8a26778f6d48" of "DICOM" content type
I1117 13:36:47.536222 PluginsManager.cpp:161] (plugins) Won't use GDCM to decode this instance of 379.5MB, as its transfer syntax 1.2.840.10008.1.2.1 is disabled
I1117 13:36:47.536502 ServerContext.cpp:1874] The installed image decoding plugins cannot handle an image, fallback to the built-in DCMTK decoder

Logs for reddish tiles:
image

I1117 13:42:35.232774 HttpServer.cpp:1262] (http) GET /dicom-web/studies/2.25.317753984268209060558780446660059290395/series/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.2.0/instances/1.2.826.0.1.3680043.2.1143.798440554347435677825371430883974737/frames/15/rendered
I1117 13:42:35.233003 OrthancPlugins.cpp:2447] (plugins) Delegating HTTP request to plugin for URI: /dicom-web/studies/2.25.317753984268209060558780446660059290395/series/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.2.0/instances/1.2.826.0.1.3680043.2.1143.798440554347435677825371430883974737/frames/15/rendered
I1117 13:42:35.233216 OrthancPlugins.cpp:4009] (plugins) Plugin making REST POST call to URI /tools/find (after plugins)
I1117 13:42:35.240644 ServerContext.cpp:1487] Number of candidate resources after fast DB filtering on main DICOM tags: 1
I1117 13:42:35.243733 ServerContext.cpp:1635] Number of matching resources: 1
I1117 13:42:35.247911 StorageCache.cpp:101] Read attachment "ff6e45b9-6493-4e0b-96c4-003c3f0817c1" with content type 1 from cache
I1117 13:42:35.257420 PluginsManager.cpp:161] (plugins) Won't use GDCM to decode this instance of 3.9MB, as its transfer syntax 1.2.840.10008.1.2.4.50 is disabled
I1117 13:42:35.257766 ServerContext.cpp:1874] The installed image decoding plugins cannot handle an image, fallback to the built-in DCMTK decoder
I1117 13:42:35.260063 DicomImageDecoder.cpp:875] Decoding a JPEG baseline (process 1) DICOM image

Config:
TRANSCODING Definition

The following Orthanc parameter leads to tiles being rendered reddish:
ORTHANC__INGEST_TRANSCODING: “1.2.840.10008.1.2.4.50”

While using the uncompressed Little Endian config:
ORTHANC__INGEST_TRANSCODING: “1.2.840.10008.1.2.1”
Renders the image correctly.

Is there an option to use the compression JPEG compression (1.2.840.10008.1.2.4.50) in combination with rendered requests?

With kind regards,
Christian

Hi,

Without any IngestTranscoding configured, the image displays fine but GDCM (the decompression library) displays warning messages in debug:

Invalid PhotometricInterpretation, should be YBR_RCT

The PhotometricInterpretation is set to RGB in the file

With IngestTranscoding set to 1.2.840.10008.1.2.4.50, GDCM still displays the same warning during transcoding.

Indeed, the image displays red.
I have tried to change the PhotometricInterpretation in the file before uploading it (tried YBR_RCT, YBR and YBR_FULL) but this did not help.

This is clearly a ColorSpace issue since the Image is mostly white (high Y value in YBR) and displays red (high R value in RGB) so an YBR image is interpreted as RGB. Since your image is in JP2K and is transcoded to lossy jpeg, there is GDCM and DCMTK involved in the transcoding and I don’t know which one is the culprit.

I would simply recommend not to use the 1.2.840.10008.1.2.4.50 (lossy syntax are not recommended anyway).

Best regards,

Alain


Sample command used:
curl http://localhost:8043/dicom-web/studies/2.25.317753984268209060558780446660059290395/series/1.3.6.1.4.1.5962.99.1.1042652702.25371455.1637425225246.2.0/instances/1.2.826.0.1.3680043.2.1143.9157464561189380521149130428932438217/frames/1/rendered --output testNoTranscoding.jpg